-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
split the qlog package into a logging and a qlog package, use a tracer interface in the quic.Config #2638
Conversation
6b43b84
to
27cedc4
Compare
"github.com/lucas-clemente/quic-go/internal/wire" | ||
) | ||
|
||
type Tracer interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any idea for a better name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. Logger maybe, but that's already taken.
type Tracer interface { | ||
TracerForServer(odcid protocol.ConnectionID) ConnectionTracer | ||
TracerForClient(odcid protocol.ConnectionID) ConnectionTracer | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll need to add another method here for logging events not related to any particular connection (e.g. stateless resets sent, Version Negotiation packets sent, packets that get dropped before they are sent to a connection, etc.).
Any suggestion for a name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why a single method, and not one per event, like in the ConnectionTracer?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Good thing about it, we don't need to come up with another name (NonConnectionTracker
?).
} | ||
|
||
// A ConnectionTracer records events. | ||
type ConnectionTracer interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make this useful, we'll have to make sure that all function parameters don't use any internal types. For most types, we can get away with defining type alias, e.g.
type MaxDataFrame = wire.MaxDataFrame
Not sure if the fact the MaxDataFrame
uses a protocol.ByteCount
(which is also an internal type) will cause any problems here.
For some types, we might want to redefine the type. For example, we don't want to pass the contents of STREAM and CRYPTO frames to the logger:
type StreamFrame struct {
Offset protocol.ByteCount
StreamID protocol.StreamID
Length int
}
Suggestion:
We'll create a new package logging/internal/to_logging, that defines conversion for these types:
func ConvertFrame(*wire.Frame) *logging.Frame
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. Maybe we can reuse this conversion in the LogFrame
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I wonder whether the Logger can eventually be yet another tracer… Probably not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be an option. We could then define a String() string
method on the logging.Frame
, and get rid of the massive switch
statement in LogFrame
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe you don't even need that String() and can just use the fmt print?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would print the contents of STREAM and CRYPTO frames.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the LogFrame wouldn't include those, and instead have useful metadata (len, etc)? I guess the downside would be that we don't get to format fields usefully (hex vs dec e.g.), but not sure whether that's worth the complexity?
Codecov Report
@@ Coverage Diff @@
## master #2638 +/- ##
==========================================
- Coverage 86.39% 86.32% -0.06%
==========================================
Files 120 122 +2
Lines 9748 9754 +6
==========================================
- Hits 8421 8420 -1
- Misses 991 999 +8
+ Partials 336 335 -1
Continue to review full report at Codecov.
|
type Tracer interface { | ||
TracerForServer(odcid protocol.ConnectionID) ConnectionTracer | ||
TracerForClient(odcid protocol.ConnectionID) ConnectionTracer | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why a single method, and not one per event, like in the ConnectionTracer?
"github.com/lucas-clemente/quic-go/internal/wire" | ||
) | ||
|
||
type Tracer interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. Logger maybe, but that's already taken.
} | ||
|
||
// A ConnectionTracer records events. | ||
type ConnectionTracer interface { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I wonder whether the Logger can eventually be yet another tracer… Probably not?
27cedc4
to
ac60622
Compare
This is the first step towards a more general logging approach, that will ultimately allow us to run both qlog and a metrics collector.