Hello,
(I sent this earlier today but it doesn't look like it made it, I
apologize if it gets through multiple times)
I am working on an application that uses a fairly simple UDP protocol to
send data between two embedded devices. I'm noticing an issue with an
initial test that was written where datagrams are received but not seen
by the recvfrom() call until more data arrives after it. As of right now
the test case does not implement any type of lost packet protection or
other flow control, which is what makes the issue so noticeable.
The target for this code is a board using the Atmel AT91SAM9260 ARM
processor. I have tested with 2.6.20 and 2.6.25 on this board.
The test consists of a two applications with the following pseudo code
(msg_size = 127, 9003/9005 are the UDP ports used):
"client app"
while(1) {
sendto(9003, &msg_size, 4bytes);
sendto(9003, buffer, msg_size);
recvfrom(9005, &msg_size, 4bytes);
recvfrom(9005, buffer, msg_size);
}
"server app"
while(1) {
recvfrom(9003, &msg_size, 4bytes);
recvfrom(9003, buffer, msg_size);
sendto(9005, &msg_size, 4bytes);
sendto(9005, buffer, msg_size);
}
As long as the server is started first and no packets are lost or out of
order, the client and server should continue indefinitely. When run
between two boards on a local gigabit switch, the application will run
smoothly most of the time, but I periodically see delays of 30 seconds
or more where one of the applications is waiting for the second datagram
to arrive before sending the next packet. Wireshark shows that the data
was sent very shortly after the first datagram, and no packets are ever
lost, ifconfig reports no collisions, overruns, or errors.
When I run the application between two identical devices on a cross-over
cable, data is transferred for a few seconds after which everything
freezes until I send a ping between the two boards in the background.
This forces the communication to start up again for a few seconds ...
