Hi, Hannes,
On 6/1/2011 11:44 AM, Hannes Gredler wrote:
...
one implementation choice could be to:
parse your input buffer up until you reach the "incomplete" PDU
which does not yet have enough payload. finally the incomplete part
gets copied back to the beginning of the buffer;
for the rpki protocol (with its small PDUs) that rebasing is a relatively
cheap operation.
| There's no way around this - even if the message says "I'm 240
| bytes", you can't know that the 240 bytes are there;
usually my buffer struct is a the buffer itself and two pointers
(start and end) for housekeeping purposes. therefore i know how
full my buffer is (buffer pointer get updated after every read
and parser call)
(see below)
| the source could have errd. You still need to grab data from the socket into
an
| intermediate space - which will be a few PDUs in length - and parse
| that, so you can get around such boundary issues and grab data off
| the socket without needing to put it back.
exactly .. all i am asking for is a constant for storing 1 PDU such that
i can appropriately size the "intermediate space"
OK, so we're talking about the same thing. I was objecting to the
concept of "PDU" - what we're talking about is the maximum length of a
self-contained parseable message. (PDUs tend to mean "packet" at L1-L4).
|>| Either way, there's no reason for a *protocol action* to deal with a
|>| receiver buffering issue.
|>
|>i find less code-complexity in input parsers a quite compelling argument.
|
| If you think you're getting around this complexity issue,
| you have a parser that has a security hole.
i have running (security audited) I/O code which works like described
above for more than a decade in the internet.
IOW i have proof point that your assertion is not correct;
Your example above *is* the complexity you claimed you were trying to
avoid...
Joe
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
