Re: Linux UDP Implementation

Dear Rick,

Thank you for your reply.

I am sorry that I don't quite understand your point. As far as I know, the 
function call udp_flush_pending_frames() in net/ipv4/udp.c is invoked 
regardless of whether the socket is set to either a blocking mode or a 
non-blocking mode. Do you mean that the implementation in the function 
sendto() handles the packet drop at the interface queue by caching data at 
the socket level ? If so, could you please advise me the Linux Kernel source 
file which contains the exact implementation of sendto() API function call 
in Linux ? I tried to locate this souce file using a bottom-up approach 
starting at the function call udp_sendmsg(), -> inet_sendmsg()  in 
net/ipv4/af_inet.c -> sock_sendmsg() in net/socket.c-> sys_sendto() in 
net/socket.c ... but I finally got lost in sys_sendto().

Thank you for your help.

Regards,

Gary

----- Original Message ----- 
From: "Rick Jones" <redacted>
To: "Gary Chan" <redacted>
Sent: Friday, September 01, 2006 1:00 AM
Subject: Re: Linux UDP Implementation

Gary Chan wrote:

quoted

According to the function call udp_sendmsg() in the source file 
net/ipv4/udp.c (Linux Kernel 2.6.17.11), when an error value is returned 
from the function ip_append_data() due to local device congestion, say 
interface queue overflow,  pending packets in the queue 
sk->sk_write_queue are simply flushed (udp_flush_pending_frames() is 
invoked) without caching for future retransmission.

I called a network API function sendto() to transmit UDP packets in a 
blocking I/O mode at a rate of 100Mbps over the 802.11b wireless ad hoc 
network, the network was overloaded as the maximum transfer rate for 
802.11b was just 11Mbps. Therefore, the outgoing interface queue must be 
full and UDP packets will be dropped eventually. However, I checked that 
there was no packet loss at the receiver side, i.e. the number of packets 
sent from the sender is equal to that received.

It seems that the implementation (at code level) does not match with the 
actual behaviour. I would like to seek expertise on clarifying my 
understanding in UDP implementation so that this phenomenon can be 
explained.

Perhaps you are seeing a difference in the behaviour of blocking vs 
non-blocking sockets?

rick jones 

-- 
VGER BF report: U 0.5