Re: UDP problem

From: Stephen Satchell (
Date: Mon Aug 26 2002 - 13:31:02 EST

At 06:29 PM 8/26/02 +0100, Murillo-Garcia Raul wrote:
> I've got a server
>application running under Windows which reads UDP datagrams and a client
>application running under Linux that sends datagrams. It seems that the more
>datagrams that arrive to the server network interface the less datagrams
>that are read by the application layer. I guess it has something to do with
>data dropping due to queue oveflow but I don't know how to prove this, much
>less how to overcome it.

Which version of Windows, and do you have the source to the "application
running under Windows"? Which Linux kernel? What else have you done to
determine the bottleneck?

If it were me doing this task, I would make damn sure I had provable
answers to the following questions:

1) What was the status return for each of the sendto()/sendmsg() calls in
the Linux client?
2) Does a sniffer show that all the UDP packets you think you sent
actually made it onto the wire? Were they routed correctly? Is there any
switch or router that could be overloaded and thus dropping packets?
3) What is the frequency of UDP packets? What is the frequency of
collisions on the network?
4) Does the Windows Winsock system see all the UDP packets? If not, how
many packets does Winsock see?
5) How much resource (CPU, memory, disk) does the processing of each UDP
packet consume?
6) What is the CPU, memory, and disk loading during the UDP packet storm?
7) Is the Windows application threaded, and if so what are the threading
8) Is there a resource lock used by the application to serialize access to
something? How long is this lock held?
9) How robust is the error recovery in the application? Can a single
request bring the server to its knees?

Once you have determined that all the UDP packets have been delivered to
the network interface card in the Windows server, you have gone beyond the
charter of the linux-net mailing list. Now, if you were to port your
server code to a Linux box, we might be able to help you by pointing to
diagnostic and debugging aides available in the Linux networking
environment. I have included questions 4-9 as a courtesy.


To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to
More majordomo info at

This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:01 EST