token-related fixes #123
token-related fixes #123
Conversation
| @@ -1817,7 +1813,7 @@ class PacketHeader { | |||
|
|
|||
| flags?: uint8; // the bit flags of the packet headers (spin bit, key update bit, etc. up to and including the packet number length bits if present) interpreted as a single 8-bit integer | |||
|
|
|||
| token?:Token; // only if packet_type == initial | |||
| token?:Token; // only if packet_type == initial || retry | |||
There was a problem hiding this comment.
So this is a bit of a difficult one imo.
I'd put retry_token outside, since it's encapsulated in its own packet type, and so it can be considered to be part of the "payload" rather than the header.
This is different from the initial token, which is clearly part of the header.
If we do put the retry token in the PacketHeader struct, imo it would make sense to do the same for the stateless_reset_token as well, since from the same logic, you could say that that is part of the Stateless Reset Packet header as well, rater than its payload.
I think it's probably cleaner to have all three in the PacketHeader then, with token?:Token covering both initial and retry as you proposed here.
|
Conclusion: remove retry_token from packet_sent and packet_received, allow using the token field on the header for Retry packets. |
Fixes #122.
This PR contains 2 fixes:
PacketHeaderalready contains aToken, so we don't need another field on thepacket_sentandpacket_receivedevent