Evaporating UDP messages

[Peter Redei]

I am wondering if there is somebody out there to help me with a UDP problem.
First of all the applications (there are many) are working fine. Typically the client is running in Windows'95 and the server on Windows'NT. The clients and the server might be in the same room or one at the East Coast the other at the West Coast.
The distance does not seems to make a difference. Both applications are writing logs of received and sent messages, that allows me to follow up what is happening.
The message size varies among applications. In most cases the message size is under 1K. In these applications I am not aware of any problem at all. In some applications the message size goes up to 8K.
When the message size is large messages are evaporating or arrive, the failure rate is inconsistant, sometimes (for a long time like hours) close to 100%, in other times (for days) close to zero.
We set the 8K limit arbitrary based on testing, running the client from Windows'98.
First I thought the older version of Wsock32.dll does not allow 8K. I reduced the size gradually to 6000 bytes without results. I can verify that the server sends the packet, but it never arrives.
I know that UDP either deliveres the message intact or not at all. I guess the reason of failure must rely on corrupted datagram, that in a very high rate caused by network (routing) problems.

My questions:
1. What are the possible reasons of this behavior?
2. How to prove it?
3. What to do for fixing the problem?

Any idea, advise welcome!

Thank you guys,

Peter Redei

------------------

[Adrian C Aitken]

As far as I know....
UDP packet size is about 514 bytes (+/-) and unlike TCP is not contention based therefore has no sequence numbers to check for the fact that the 1st packet is 1st,2nd is 2nd etc.
Therefore it is up to the programmer (ie you !) to do ALL error checking.
If you do large transfers of data over any distance you should convert to TCP !

Hope this helps

Adrian

------------------

[Peter Lameijn]

You should test the maximum size of packets allowed on both sides:

  GetSockOpt lSock, %SOL_SOCKET, %SO_RCVBUF, lRet, SizeOf (lRet)
  Print "Max UDT receive buffer size: " + Str$(lRet)
  GetSockOpt lSock, %SOL_SOCKET, %SO_SNDBUF, lRet, SizeOf (lRet)
  Print "Max UDT send buffer size: " + Str$(lRet)

(You should test this at both sides of the UDT connection)
Also what I always do, is give all packets a sequence number. Keep a
queue of the last 5 or so sent packets. If one packet is missing, the
receiver can just ask for a resend of a packet......

------------------
Peter.
mailto[email protected][email protected]</A>



[This message has been edited by Peter Lameijn (edited August 03, 2001).]

[Guest]

You might want to reconsider the 8k message length. (I think most ethernet cards have a magic number of about 1500 bytes). This requires multiple ethernet packets and increases the chance of packet timeout (and death). You do know that the packets are not guarranteed to arrive in the order they were sent? When I use UDP, I have created a packet wrapper (protocol) and crc. This
is slower than streaming but an ACK/NAK, timeout and packet numbering scheme makes for a reliable and manageable UDP session with little devices all over the place...

[Peter Redei]

Thank you for all responses.
Using GetSockOpt a little bit surprised me. It returned for both buffers 8K (that is the same that I anticipated) in Windows'98 and 'NT, but for Windows'95 for both was over 10,000 bytes (I anticipated less or 8K).
The problem still exists. We are getting to put a sniffer on it. The UDP messages are already sent in more packets when the size requires it and each packets are numbered. This is a very fast application for telephone operators. There is no time for communication back & fore and for resending packets.
The 1500 bytes limit indeed exists, but that means an automated fragmantation/defragmantation, so it should not effect the size of the packets. In fact, it doesn't, in most of the time it works just fine.

Regards,


Peter Redei

------------------

[Lance Edmonds]

UDP (being connectionless) is best used for apps that can cope with some data loss (UDP is usually used for purposes such as audio/video streaming, etc). In your app, using TCP would make more sense since the connection between client & server can be controlled.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Peter Redei]

Lance,
I am sure you and others are right, TCP would be a better choice. Yet, there is no way to change. I inherited UDP, that is used by several applications, and I doubt if the company would welcome any change. The failure rate on UDP in normal circumstances is very low (about 30 out of 40,000). The problem is when the circumstances are not normal and the failure rate jumps to a significant value. What I am looking for is the reason why suddenly the failure rate jumps.
Thanks for your input.

Regards,

Peter Redei

------------------

[Lance Edmonds]

The problem is most likely to be network related, so please let us know what you find with the sniffer...

Out of curiousity, what sort of network is it? Lots of switches/routers? Any chance of monitoring these to see where the broadcasts are getting lost?


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Peter Lameijn]

Sometimes concurrent TCP traffic can influence UDP traffic. See:
http://www.isoc.org/isoc/whatis/conf...gs/F3/F3_1.HTM

------------------
Peter.
mailto[email protected][email protected]</A>

[Peter Redei]

Peter, thank you for the article. This was very helpful because describes exactly what we are experiencing. Unfortunately it does not really provide resolution. It seems to me there is not much to do, using UDP one has to accept lost packets.
Lance, I do not have detailed information about the network. Beside that, there are various networks connected with T1. The one we are using for testing is a combination of Novell and NT. The problem occurs almost in all, perhaps in different weight.
We can live with a very low number of lost packets (that is not always the case).
We will install the sniffers tomorrow. I will let you know the results.


Regards,


Peter Redei

------------------