Comments (3)
So I'm currently breaking my head on this one as there are a lot of aspects to closing connections in QUIC:
- there are three different states: closing, draining, actually closed
- there are many different reasons for "closing": idle timeout/handshake timeout, "immediate close", stateless reset, no overlapping versions, ...
- within immediate close, there are different error spaces: connection errors, application errors (which don't always reflect the actual internal error properly)
Currently (see draft02 branch), these things are kind of spread out across three different events:
- connectivity:connection_state_updated
- generic:connection_error
- generic:application_error
Combining this into a single connection_closed
event with all that flexibility would thus lead to some serious duplication across the board..., not to mention a very complex event
However, looking at https://github.com/lucas-clemente/quic-go/pull/2501/files, which seems the main use case for @marten-seemann at least, all he really cares about is logging a free-form string "reason" for a connection_closed event, as well as having a separate event type so it's easy to query just the connection_closed
, instead of having to sift through connection_state_updated
.
So, my proposal would be to add connection_closed
as a quite high-level event, mainly useful for manual interpretation, referring to the other existing events if the need arises to log more fine-grained info.
Thus, the proposed design of connection_closed
for draft-02:
{
owner?:"local"|"remote",
connection_error_code?:uint32,
application_error_code?:uint32,
reason?:string
}
Triggers:
* clean
* handshake_timeout
* idle_timeout
* error // basically the "immediate close" case
* stateless_reset
* version_mismatch
(reminder, in qlog, each event has an implicit trigger field, which can contain any string value, so other triggers would be valid here as well)
I'm not particularly happy with this design, but it's better than others I could come up with.
Does this suit your use case @marten-seemann? Can you let me know by tomorrow evening (2nd November)? Thanks!
from qlog.
Why do we need generic:connection_error
and a generic:application_error
?
from qlog.
Merged connection_error and application_error with connection_closed, as that indeed makes more sense here.
Closing for now, open to revisiting this for draft-03.
from qlog.
Related Issues (20)
- H3Settings is a bit underspecified HOT 4
- packet_sent doesn't allow logging of IP address (for packets sent outside of a connection) HOT 4
- `ConnectionClose` storing a uint64 error_code and a uint64 error_code_value seems redundant HOT 4
- Split out ECN "capable" state HOT 1
- Difference between negotiated vs actually accepted/enabled TPs HOT 2
- Logging spin bit policy HOT 2
- Give concrete guidance on how to extend qlog
- Connectivity::Connection_closed application trigger type is confusing HOT 1
- Logging non-UTF-8 reasons HOT 2
- Logging of HTTP field names or values that contain illegal bytes
- Discuss extensibility of extension points through type or group sockets
- Make logging raw byte values consistent
- Move Trigger section underneath Data section
- Register application/qlog+json and application/qlog+json-seq media types
- protocol_type or protocol_types
- How is "trigger" a common subfield of "data"? HOT 1
- is parameters_restored missing fields defined in parameters_set?
- Extensions to events can not be indicated by schema
- JSON-SEQ is painful HOT 14
- parsing the `serialization_format` field requires prior knowledge of the serialization format HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qlog.