Extend qlog support #4201
Extend qlog support #4201
Conversation
- support QLOGDIR environment variable - support chosen_alpn qlog event - support stream_data_moved event
There was a problem hiding this comment.
Can you split this up into 3 separate PRs?
- The ALPN event totally makes sense to me.
- What's the motivation for the stream_data_moved event? How would you use it?
- The QLOGDIR should be optional, i.e. not be implemented in the
quicpackage. Having a separate constructor in theqlogpackage makes sense to me.
| @@ -34,6 +35,8 @@ type ConnectionTracer struct { | |||
| LossTimerExpired func(TimerType, EncryptionLevel) | |||
| LossTimerCanceled func() | |||
| ECNStateUpdated func(state ECNState, trigger ECNStateTrigger) | |||
| ChoseAlpn func(protocol string) | |||
There was a problem hiding this comment.
It would be nice if we could also log server_alpns and client_alpns, but it doesn't seem possible without wrapping various callback on the tls.Config, which we should avoid doing.
| ChoseAlpn func(protocol string) | |
| ChoseALPN func(protocol string) |
I can :)
I would like to test/benchmark the "end-to-end"-performance that I can expect on the application layer in some scenarios. From the current qlog it is not obvious how far a stream has progressed, because of loss and reordering. For now I have a Python script that tracks the stream gaps from the qlog stream 😅
Not sure if I understand you correctly, you mean just a separate NewQlogDirConnectionTracer? |
Yes, pretty much. Then we can tell users "If you want to record qlogs every time the QLOGDIR is set, set the |
|
Closing, since we've had support for the ALPN event and the QLOGDIR for a while now. Still not sure what to do about the data moved event. |
Covers #4189