gamedevlists-general

Re: [GD-General] UDP questions

[brian h. <bri...@py...>]

> What are your sources?

Well, my two sources are the following (via gamedev.net) 
and "everything else I've ever read" (i.e. Stevens, WinSock references, 
etc.).

http://www.ecst.csuchico.edu/~beej/guide/net/html/advanced.html#sendall

In the above, which is written in a fairly authoritative tone, there 
are a couple pieces that made it sound like you could receive packet 
fragments instead of entire packets.  That's the part that confused me.

Specific excerpts:

"Likewise, when you're receiving this data, you need to do a bit of 
extra work. To be safe, you should assume that you might receive a 
partial packet....We need to call recv() over and over again until the 
packet is completely received.
.
.
.
Every time you recv() data, you'll feed it into the work buffer and 
check to see if the packet is complete. 
.
.
.
Well, here's the second of the one-two punch: you might have read past 
the end of one packet and onto the next in a single recv() call. That 
is, you have a work buffer with one complete packet, and an incomplete 
part of the next packet!"

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).

Brian

RE: [GD-General] UDP questions

[Jaek S. <smi...@cs...>]

> 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).

Taking an extremely quick look at the link you sent, it looks like the methods he is showing are for a stream (TCP) socket, and not a datagram (UDP) socket.  Ex:

   if ((listener = socket(AF_INET, SOCK_STREAM, 0)) == -1) {

Thus... he is probably doing a message-over stream based protocol.

Calling recv will receive a single, complete datagram.  However, the following may be true (does someone want to verify these):

  - It may not be unique
  - It may be corrupt
  - It may be out of order

Later for now
--Jaek

RE: [GD-General] UDP questions

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

> Taking an extremely quick look at the link you sent, it looks 
> like the methods he is showing are for a stream (TCP) socket, 
> and not a datagram (UDP) socket.

Yeah, he bounces around a bit between the two.

I'm leery of saying the guy is wrong, because the guide is extremely
comprehensive -- I don't see how you could write something that big and
in-depth and screw up something as fundamental as UDP packet delivery
constraints.  So I was assuming I didn't understand what he was saying
(entirely likely).

> Calling recv will receive a single, complete datagram.  

Which his comments contradict.  This would seem _especially_ true of a
TCP implementation.

> However, the following may be true (does someone want to 
> verify these):
> 
>   - It may not be unique

True.

>   - It may be corrupt

This I'm not sure about -- isn't a CRC check part of the UDP and TCP
protocols, or is this something that every application is expected to
implement?  I know that some application protocols do CRC (e.g. Quake)
but I was under the impression this was more to stop cheating, not to
verify that the data wasn't corrupted.

>   - It may be out of order

Definitely.

Brian

RE: [GD-General] UDP questions

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

> calling recv for tcp will give you a certain amount of data.  
> it doesn't necessarily correspond to any sort of packet.  
> Remember, tcp is a stream protocol, so it doesn't understand 
> datagrams.

Ah-ha!  Okay, duh -- I've never actually even considered using TCP, so
that's where the confusion comes from.  So his tutorial was, in fact,
correct, it was just the context (TCP) that was confusing me.

> the protocol verifies that CRCs match for the packet.  That's 
> about it. Application protocols should verify their own CRCs 
> to make sure the packet is legitimate.

Define "legitimate"?

Brian

RE: [GD-General] UDP questions

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

> > Define "legitimate"?
> 
> Legitimate is defined as a packet that was really generated 
> by the client or server, as opposed to spoofed or otherwise 
> crafted by a third party program sitting in the middle.

Okay, that's easy enough to deal with -- all my network traffic is
encrypted with a randomly generated session key that's delivered with
RSA encryption to the server.  On top of that I also have
username/password authentication, so doing a man-in-the-middle attack
should be pretty much impossible.

I was more worried that I would need to do another checksum just to make
sure that the data wasn't inadvertently corrupted.

Brian

RE: [GD-General] UDP questions

[Jaek S. <smi...@cs...>]

> >   - It may be corrupt
> 
> This I'm not sure about -- isn't a CRC check part of the UDP and TCP
> protocols, or is this something that every application is expected to
> implement?  I know that some application protocols do CRC (e.g. Quake)
> but I was under the impression this was more to stop cheating, not to
> verify that the data wasn't corrupted.

TCP definately is guarenteed data-wise, order-wise, etc.

UDP, however, uses only a quick CheckSum - which, I believe, can be turned off.

With a quick search, here's a quote:

  "the Internet checksum is not foolproof ... it is still
  possible that there are undetected errors in the segment.
  For this reason, a number of protocols use more
  sophisticated error detection techniques than simple
  checksumming."
  ( http://www-net.cs.umass.edu/kurose/transport/UDP.html )

Also, another quote (from the same page):

  "Although UDP provides error checking, it does not
  do anything to recover from an error. Some implementations
  of UDP simply discard the damaged segment; others pass the
  damaged segment to the application with a warning. "
  ( http://www-net.cs.umass.edu/kurose/transport/UDP.html )

I can't guarentee the quality of the above information.  However, it matches my understanding from when I studied the TCP/IP protocol several years ago.  (If only my memory weren't volatile I could guarentee my answers also, heh).

About a year ago I found out about a protocol being developed (that I think was being build on top of IP - same layer as TCP and UDP) that did guarenteed messaging.  I can't remember the name - should see if I can find some info / status.  Streams are just so wrong in the world of software data communications. :P

Later for now
--Jaek

Re: [GD-General] UDP questions

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

On Sun, 30 Jun 2002, brian hook wrote:

> > What are your sources?
> 
> Well, my two sources are the following (via gamedev.net) 
> and "everything else I've ever read" (i.e. Stevens, WinSock references, 
> etc.).
> 
> http://www.ecst.csuchico.edu/~beej/guide/net/html/advanced.html#sendall
> 
> In the above, which is written in a fairly authoritative tone, there 
> are a couple pieces that made it sound like you could receive packet 
> fragments instead of entire packets.  That's the part that confused me.

Thankfully, I read it as Stevens agress with what I wrote. I would trust 
him. I would even trust the winsock docs in this case.... :-)

Maybe someone else have another 2 cent?

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
There has never been a good war or a bad peace.
                           - Benjamin Franklin