[GD-General] RE: Gamedevlists-general digest, Vol 1 #79 - 3 msgs

[Jeff L. <je...@SP...>]

> Given the feedback from you and others, however, it looks 
> either Beej's 
> comments are wrong, or what he defines as a "packet" is 
> something other 
> than a UDP packet (e.g. his own packet structure, etc.) and thus 
> possibly something that can become fragmented.  From looking at it, 
> though, it doesn't seem to be the case (i.e. the example he 
> gives of a 
> simple chat protocol shouldn't have a case where it fragments at the 
> application level).

The key here is that you are blurring UDP packets with "amount of data sent
to send()" or "amount of data that comes back from recv()".

Both of these routines buffer (which he does allude to in 6.3).

recv() might return an incomplete packet, because you pass it a length of
the amount of data you are prepared to read.  It doesn't return when it
reaches the end of a UDP packet, or when it reaches the end of what the user
passed to send().

Thats the whole point of the article, to my eye.  Establishing a protocol
such that the sender includes enough information that the reciever knows
where the packet boundaries are, once their udp packets have been converted
into a meaningless byte stream (which is what the buffering inside recv()
does for you)