UDP Server

[Nak]

Hi there,

I have made a UDP server and client class in VB.NET but am experiencing
problems with receiving datagrams beyond a certain size (though I am unsure
of the exact limit). I wish to send quite significant amounts of data via
UDP and certain sources on the internet recommend that I do *not* use the
"udpclient" class but make a new class which uses the "sockets" class and
receive the data asynchronously. Does anyone know of any examples around
that are capable of this? VB.NET / C#, I don't mind, thanks in advance.

Nick.

 

[Nak]

Hi again,

I've just come across a free sockets library called indy, i'm hoping
that this is capable of recieving large UDP datagrams, but am unsure as yet
as I can't find the relevant information on how to get the thing working.
If anyone else has used this, please let me know!

Nick.

 

[Peter Huang]

Hi,

I think a UDP packet has the maximum size of a UDP datagram is 65507
bytes.(about 64 kb)

Theoretically, the maximum size of an IP datagram is 65535 bytes, imposed
by the 16-bit total length field in the IP header.(See the figure below)

A summary of the contents of the internet header follows:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Example Internet Datagram Header

With an IP header of 20 bytes and a UDP header of 8 bytes, this leaves a
maximum of 65507 bytes of user data in a UDP datagram.

Since this is caused by the nature of the UDP, to workaround the problem,
we would better to split the data based on 64kb, i.e. if we need to
transport the data over 64kb, we can split it into a few udp packets, and
then rearrange them in the server side. To indicate the data order, we need
to spare a few bytes in the head of the udp packet, so that in the server
side we know how to rearrange them. All this relied on how you implement
the algorithm.

Hope this helps.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Nak]

Hi Peter,

I was fearing this, and hoping that the UDP protocol would spit my data
into the necessary sizes. *But* I still believe there is a problem here,
just mainly down to what I read on Code Project regarding a bug with the
"Receive" method of the UDPClient.

http://www.codeproject.com/buglist/udpclientbug.asp

I just hope that doing as you suggest will have the desired effects and
enable me to perform file transfer via UDP, I've implemented MD5 Hashing to
check that data arrives correctly but this is a whole lot more to implement,
oh well, such is life!! Thanks for the advice Peter, I shall try that now.

Nick.

 

[Peter Huang]

Hi Nick,

Yes it is a known issue, and the problem has been resolved in the Everett
(VS.NET 2003).
If you still have any concern on this issuem, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Nak]

Hi Peter,

Yes it is a known issue, and the problem has been resolved in the Everett
(VS.NET 2003).
If you still have any concern on this issuem, please feel free to post

here.

Unfortunately developing for 1.1 of the framework is still not possible
for myself, but I shall do *soon*. Thanks allot for your help though, at
least I know what needs to be done now.

Nick.