So having a conversation with myself here as I think more about these issues...
I take back what I said about the overlay specific data. This info is coming from the config, without which a peer can't join anyway, and otherwise many things (including peerids) will need lengths, so I think the overlay specific data not having a size is fine as is, so long as the length is in the config. Love to hear other thoughts on it, however. Still think there is an issue with extension needing length, however... Thanks, David (as individual) On Jul 8, 2010 10:58 AM, "David A. Bryan" <[email protected]> wrote: So looking at the extension mechanism in 5.3.3...is there a reason that the MessageExtension object (5.3.3) has no length? I may have just missed something obvious, but it seems it needs to have one, if you want to allow multiple extensions where intermediate peers might not understand the opaque data. If for example we had two extensions, a message (I'll use a join for this example) might look like: Forwarding Header Message Contents message_code message_body JoinReq joining_peer_id (NodeID) overlay_specific_data (variable length) extensions ....extension 1.... ....extension 2.... Security Block Let's take a hypothetical case where a peer receiving this understands extension 2, but not extension 1. Even if extension 1 isn't critical and it knows the type, since what follows is opaque data, if it doesn't understand the extension, how does it know how long that block of opaque data is before getting to extension 2? Perhaps we need to change MessageExtension in 5.3.3. to include a length prior to the opaque data? While we're on this, there are several places where the parser seems to need to know about overlay specific/generic data just to to parse. The one above seems like it truly won't work without a length (since we explicitly want to allow for non-critical extensions), but others, for example the variable overlay_specific_data in some messages (for example this join) seem to imply that while it will work, the low level parser itself needs to know about the overlay specific data (since this can vary by overlay, not implementation). A parser that doesn't support that overlay parameter can't even parse the message (I don't think it can even know where the security block starts, so it technically can't even verify the signature, unless it reads backwards from the end or something, correct?) It seems like you need to have the extension-specific/overlay-specific code inside the basic parser...or am I missing something? (i.e., you can't write a generic parser that can parse any message, it needs to have contextual awareness) If this was a deliberate design decision it seems problematic. I personally don't really like the idea that a parser needs to understand the overlay specific data just to parse the message. Obviously you can do this with plug in code or something, but then we are forcing a particular implementation/design in the design of the protocol, and the extra bits (lengths) here and there that would allow a parser to process a message without the extensions simply aren't that heavy. It seems like a better design to allow a basic RELOAD parser to parse any message, passing specific data up to be decoded by higher levels. David (as individual)
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
