By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,026 Members | 2,085 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,026 IT Pros & Developers. It's quick & easy.

UDP and Packet size

P: n/a
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
Nov 16 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
SRLoka wrote:
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
Nov 16 '05 #2

P: n/a
> 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" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com... SRLoka wrote:
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

Nov 16 '05 #3

P: n/a
SRLoka wrote:
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 ?


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

Thanks for the reply
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:

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


Nov 16 '05 #4

P: n/a
SRLoka wrote:
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 ?


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

Thanks for the reply
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:

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


Nov 16 '05 #5

P: n/a
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.

"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:
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 ?


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

Thanks for the reply
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:
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 alarge 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


Nov 16 '05 #6

P: n/a
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.

"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:
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 ?


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

Thanks for the reply
"Robert Jordan" <ro*****@gmx.net> wrote in message
news:ch*************@news.t-online.com...
SRLoka wrote:
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 alarge 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


Nov 16 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.