Skip site navigation (1)Skip section navigation (2)
Date:      01 Jul 1998 14:19:23 +0200
From:      smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav)
To:        net@FreeBSD.ORG
Subject:   Length of incoming UDP datagrams
Message-ID:  <rx4yaud4vck.fsf@oslo.geco-prakla.slb.com>

next in thread | raw e-mail | index | archive | help
Is there any way to obtain information about the length of an incoming
UDP datagram short of actually receiving it in a large enough buffer?
It seems strange to me that there should be no way to know ahead of
time how much memory to allocate for a datagram. Of course, you can
resort to trial and error: allocate a buffer, peek at the message, if
the length returned by recvfrom() is shorter than the length of your
buffer you're done, otherwise grow your buffer and try again; but it
seems an extreme waste of CPU time to me (especially because most of
what you're doing is copying data from kernel space to user space...
and after you have ascertained the length of the datagram, you still
have to remove it from the input buffer by performing an additional
recvfrom(), this time without MSG_PEEK)

I have also thought of doing a getsockopt(sd, SOL_SOCKET, SO_RCVBUF,
&val, &len) and allocating a buffer of that size once and for all, but
it always returns 0 (the alternative, of course, is to select a buffer
size myself and force it upon the socket with setsockopt()). Anyway,
is there a guarantee that no incoming datagram will exceed that size?
And what happens to datagrams that *do* exceed that size? Are they
silently dropped by the transport layer?

DES (puzzled)
-- 
Dag-Erling Smørgrav - smoergrd@oslo.geco-prakla.slb.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?rx4yaud4vck.fsf>