Comments (4)
Thinking about this more, this seems to have become an untenable situation going forward to -03.
qlog straddles the weird line between being a replacement for pcaps, as well as having to provide events for logging conceptual events not reflected in pcaps.
This was fine in the beginning, as everyone can/did log packet contents (e.g., ACK frames) and we could skip many events related to things clear from the wire (e.g., packet_acked
or flow_control_updated
etc.). However, for implementations that would not want to log the wire image itself, we would have to add these latter types of events for everything... (ref #107). Tools would then also have to be flexible enough to get this info both from frames and these other events.
Long story short: we're tying to be a one-stop-shop, defining everything. That might be fine, but then we probably need to explicitly and quite clearly split up the wire-image events from the conceptual events (and provide alternatives for all and clear guidance).
This really could use wider discussion.
from qlog.
We had a clear example today of how a separate flow_control_updated
event is useful. A misbehaving client was lowering flow control limits (probably because it retransmits FC frames as they were in the past, rather than create a new FC update with new limits). qvis showed this as lowering the limits, even though the server probably didn't actually apply the lower limits at its end. It was good that qvis showed the limits (leading to the discovery of this problem), but it again highlights that there is a difference between receipt of a given frame and how that's actually applied in the implementation.
from qlog.
Sounds like we want to focus on transport-related events in qlog and tell people that logging what your implementation_does_ with those can aid analysis or debug. This is an implementation choice. And general-purpose tooling is unlikely to support implementation-specific needs or data. I'd think most people could live with that because it is logical.
What else might we want to say?
In future, if people are always logging some application-specific field and want to ask their tool vendor to support it. That's probaby a good time for them to engage in the community.
from qlog.
Marking this as editorial since I don't think there's anything we can do apart from reiterate that qlog doesn't cover everything and that it extensible enough to support individual needs.
Requests for adding design changes to these drafts can be raised as new issues (albeit at this stage likely to be declined unless there is sufficient evidence that it is needed).
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.