UDP and Packet size

[SRLoka]

I am designing a UDP server(still on paper) that will receive data from
various client applications(residing on PocketPCs using GPRS)
I am using Richard Blum's 'C# Network Programming' as my guide.
One thing I wanted clarification on was, when the author says "UDP
maintains message boundary", does it mean that the Server will always
receive an entire message or not receive it ? What if the Client sends a
large message(say 5K) and it gets broken into multiple packets in the
process of transmission across networks(I was reading on newsgroups that its
possible), does it get reassembled before it reaches the server ? Can only
part of the message ever make to the server ? Is there anyway I can check on
the server side that the message is not whole/complete ?
If it is that the wholeness of a message can be verified on the
Client/Server, I do not want to get into breaking a message into smaller(512
bytes) and then reassembling them. That will add a lot of complexity. 80% of
our messages are well under 500 bytes. So a few retransmissions(just
assuming the probability of breaking a message by the network is low) will
be better than the complexity of splitting/combining messages.

Thanks in advance for any info.


Srinivas

 

[Robert Jordan]

I am designing a UDP server(still on paper) that will receive data from
various client applications(residing on PocketPCs using GPRS)
I am using Richard Blum's 'C# Network Programming' as my guide.
One thing I wanted clarification on was, when the author says "UDP
maintains message boundary", does it mean that the Server will always
receive an entire message or not receive it ? What if the Client sends a
large message(say 5K) and it gets broken into multiple packets in the
process of transmission across networks(I was reading on newsgroups that its
possible), does it get reassembled before it reaches the server ?

Yes, they get reassembled. It's called IP-Fragmentation and it's
handled by the IP-protocol (the underlying protocol of UDP).

Can only
part of the message ever make to the server ?

No.

However, you still must deal with these situations:

- a packet may never arrive
- a packet may arrive in the wrong order

So you must mark the packets with a sequence number
or design your protocol to be stateless.

bye
Rob

 

[SRLoka]

However, you still must deal with these situations:

- a packet may never arrive
- a packet may arrive in the wrong order

We have a strategy for dealing with "packets never arriving". We will use
"ack" and retry tineouts.
All our packets are independent of each other. All of them are simple
messages like a chat program. So does that mean we never have to worry about
packet order ?

Thanks for the reply

 

[Robert Jordan]

We have a strategy for dealing with "packets never arriving". We will use
"ack" and retry tineouts.
All our packets are independent of each other. All of them are simple
messages like a chat program. So does that mean we never have to worry about
packet order ?

The packets may be independend, but they may contain
informations your application is expecting in a certain order.
Try to design the protocol to be stateless, that means:
at any time you must be able to handle any message w/out the
knowlege of what happend before.

bye
Rob

 

[SRLoka]

Thanks. That helps a lot.
Our app does not need the messages in any order. There are simple
notifications and the receiving app has no logic that dependes on the
message order.