gamedevlists-general

[GD-General] UDP questions

[Brian H. <bri...@py...>]

I'm working on a basic UDP implementation right now and I'm running into 
conflicting information on packet fragmentation.

My understanding of UDP is that it's unreliable, unguaranteed, and 
basically not going to get you data in any particular order or even at all.

Fine, I can deal with that.

BUT, if it DOES get you data, that data is supposed to be "complete".  In 
other words, if Server sends a packet of 500 bytes to Client, then Client 
will either receive that packet or none at all when it calls recv() 
(assuming that the recv() buffer is large enough).  Yes?

I know that Server->Client can result in the packet becoming disassembled, 
fragmented and munged along the way by various routers (or even by the 
server's network layer), but I was assuming that the packet reconstruction 
in the socket driver was reasonably advanced -- i.e. it was responsible for 
making sure that a fully constructed and CRC-verified packet was actually 
sent down to the Client's socket (if at all).

If I get get a positive return value from recvfrom(), can I assume that 
it's a single complete packet?  Is it possible that I'll receive multiple 
packets in a single call to recvfrom()?  Is it possible to receive a 
partial packet?

If so, this means that my simple code is now going to be gross and nasty -- 
specifically, I'm going to have to create and maintain intermediate work 
buffers for every client connected to my server. Blech.

I know that send() can deliver less than the number of bytes you request, 
but that's easy enough to handle.

Anyway, before I get too far into my networking layer, I just want to make 
sure that I don't A.) overengineer for situations that won't happen or B.) 
make something that's not robust.

Thanks,

Brian

Re: [GD-General] UDP questions

[Mads B. D. <ma...@ch...>]

On Sat, 29 Jun 2002, Brian Hook wrote:

> I'm working on a basic UDP implementation right now and I'm running into 
> conflicting information on packet fragmentation.

What are your sources?

> 
> My understanding of UDP is that it's unreliable, unguaranteed, and 
> basically not going to get you data in any particular order or even at all.

Same here.

> Fine, I can deal with that.
> 
> BUT, if it DOES get you data, that data is supposed to be "complete".  In 
> other words, if Server sends a packet of 500 bytes to Client, then Client 
> will either receive that packet or none at all when it calls recv() 
> (assuming that the recv() buffer is large enough).  Yes?

That is my understanding: the fragmentation you are worrying about is on 
the IP level, ie, the UDP packet _might_ be fragmented into several IP 
packets. The IP layer should handle this, iff all packets arrive. If not, 
you loose the UDP packet.

> If I get get a positive return value from recvfrom(), can I assume that 
> it's a single complete packet?  

For UDP, yes, this is my understanding.

> Is it possible that I'll receive multiple 
> packets in a single call to recvfrom()?  Is it possible to receive a 
> partial packet?

Don't think so.

> I know that send() can deliver less than the number of bytes you request, 
> but that's easy enough to handle.

I am unsure how send() works with UDP packets. I would assume that it is 
ready to handle all valid UDP packet sizes.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
On the other hand, we can agree with Microsoft that the GPL is bad for
their current business. We can then proceed to use Microsoft's favorite word
as we reply: Innovation won't stop just because you're not ready for it. The
printing press was a good thing, after all, even though it forced
professional scribes to change their business model. Adapt or die
                               - Chip Salzenberg