You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 11, 2020. It is now read-only.
Describe the solution you'd like
It would be really handy to know the current number of opened streams on a session at the ngtcp2 level. This would make it easy to identify leaking streams (i.e ones lost in the Javascript client) but still open due to not (yet) exceeding the idle time.
This is supplementary to the current counters providing the total number of opened streams since session establishment.
Describe alternatives you've considered
Of course the user could wrap the QUIC system to provide tracking like this. However as this relates to finding a common possible developer error it might be best to provide it in the core. Further as the Native module can likely (confirm?) extract this from ngtcp2 or it's own data it can likely provide a more reliable source for this data.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Is your feature request related to a problem? Please describe.
Related to #383 and #386
Describe the solution you'd like
It would be really handy to know the current number of opened streams on a session at the ngtcp2 level. This would make it easy to identify leaking streams (i.e ones lost in the Javascript client) but still open due to not (yet) exceeding the idle time.
This is supplementary to the current counters providing the total number of opened streams since session establishment.
Describe alternatives you've considered
Of course the user could wrap the QUIC system to provide tracking like this. However as this relates to finding a common possible developer error it might be best to provide it in the core. Further as the Native module can likely (confirm?) extract this from ngtcp2 or it's own data it can likely provide a more reliable source for this data.
The text was updated successfully, but these errors were encountered: