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?
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 */
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?
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?
Thanks,
Andy
p.s. your Mail-followup-to wanted to send to both the list address and
your own. I wasn't certain if this is what you intended, so I removed
your address. :-)
