On Sat, Sep 11, 2010 at 09:27:51AM -0600, Andy Bradford wrote: > Thus said Claudio Jeker on Sat, 11 Sep 2010 11:28:31 +0200: > > > Wrong UDP is normaly not a fully defined 4 touple. Especially the > > listening sockets (on port 53) can be slammed with packets. On the > > other hand, if the recvbuffer overflows then packets just get dropped. > > Thank you for the clarification. So basically, when a socket is in the > LISTEN state, if 80 1k UDP packets are sent concurrently to the server > from 80 different source IPs, then roughly 50% of them will be dropped > (assuming defaults), because the recvspace is dedicated only to this one > socket.
There is not LISTEN state on UDP sockets (those are stateless). It just matter that the destination (remote address) was not specified. But yes, if to many clients hammer the server it will drop packages. > The recvspace for a response of DNS, on the other hand, isn't likely to > be consumed because the only packets coming to it will be response > datagrams from a single server answering the query, and even with > DNSSEC, and an answer as large as the one returned for an ANY query of > bugs.debian.org, the recvspace isn't likely to be flooded. Not necessary correct. Since it is possible to query multiple server at the same time with a single UDP socket. AFAIK DNS server tend to use a bunch of sockets to send all the packets. They do not create a new socket for each and every lookup. This is possible because UDP can use sendto() and recvfrom(). > TCP is the same except a socket is more distinct because of the > connection tuple so the recvspace is more dedicated. > On TCP the send/recvspace is always dedicated to one single connection. There is no direct sharing of resources there. > > The sendto() ENOBUFS errors that got mentioned have a different cause > > (in most cases the interface send queue is overflowed). > > Yes, I suspected that this reported error was unrelated to send/recv > space, because once the recvspace is full. For UDP and all SOCK_DGRAM sockets the sendspace only limits the size of a single packet. So a sendspace of 1k would only allow 1k messages to be sent because the packet is added to the sendbuffer and then passed to udp_output where it is directly moved out to the HW. It is not possible to store more then one packet in the sendbuffer. -- :wq Claudio
