On Fri, Sep 10, 2010 at 08:20:30PM -0600, Andy Bradford wrote: > Thus said Claudio Jeker on Fri, 10 Sep 2010 21:36:16 +0200: > > > Because on busy servers you need to queue quite a few packets to > > handle bursts. > > I was under the impression that UDP is connectionless and therefore > does not behave the same as a TCP connection. I would guess that > send/recvspace for UDP relates somehow to the size of a UDP datagram, > and that even if these UDP datagrams came in bursts, they would not be > part of the same send/recvspace. Please correct me if I'm wrong as this > is something I've been confused about. Is there possibly some kind of > abstraction that treats UDP as connection oriented with respect to > send/recvspace? >
The send/recvspace is for one socket. So for the listening socket all lookup requests end up on the same socket and so on the same recvspace. > After digging around a bit more I found the following in > /usr/src/sys/netinet/udp_usrreq.c which suggests that at least sendspace > is merely the datagram size: > > u_int udp_sendspace = 9216; /* really max datagram size */ > u_int udp_recvspace = 40 * (1024 + sizeof(struct sockaddr_in)); > /* 40 1K datagrams */ Yes, the comments are correct. > > Even if in general all UDP datagrams from the same IP:PORT-IP:PORT combo > go into the same recvspace, DNS does not normally use more than one > packet for a response, and other responses will not match due to port > randomization. Even with DNSSEC and EDNS0, should the default of 40 1K > datagrams be sufficient to handle DNS packets? > 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. The sendto() ENOBUFS errors that got mentioned have a different cause (in most cases the interface send queue is overflowed). > It's entirely possible that I have completely misunderstood how > recvspace relates to connections (I haven't yet found a good exposition > of this anywhere). Is recvspace per UDP/TCP connection or more of a > generic space for TCP/UDP packets, regardless of connection? > The recv/send space is per socket. For TCP it is the same as a connection. UDP has no connections so all packets that you receive on that socket share the recvspace. -- :wq Claudio
