recvfrom() vs recv() with UDP protocol - Unix
This is a discussion on recvfrom() vs recv() with UDP protocol - Unix ; Usually, recvfrom() seems to be used with UDP, because it allows you
to specify an address to a connectionless socket. However, I've seen
source code before (a DNS client) which used recv() to receive
incoming UDP packets.
My own experiments ...
-
recvfrom() vs recv() with UDP protocol
Usually, recvfrom() seems to be used with UDP, because it allows you
to specify an address to a connectionless socket. However, I've seen
source code before (a DNS client) which used recv() to receive
incoming UDP packets.
My own experiments show that when polling 100 sockets for incoming UDP
packets, if I use recvfrom() I get on average almost twice as many
POLLIN events than when I use recv(). In other words, when I use
recv(), a lot more packets are lost. So obviously, recvfrom() seems
to be a lot more reliable when dealing with UDP packets.
However, this is based only on my own observations. I have never seen
this documented anywhere. Is this effect unique to my OS, (Linux 2.6)
or is it generally understood that recvfrom() should *always* be used
with UDP connections?
-
Re: recvfrom() vs recv() with UDP protocol
chsalvia@gmail.com wrote:
> Usually, recvfrom() seems to be used with UDP, because it allows you
> to specify an address to a connectionless socket. However, I've
> seen source code before (a DNS client) which used recv() to receive
> incoming UDP packets.
recvfrom() does not allow one to specify an address to a
connectionless socket. It gives you the source IP address from whence
the arriving UDP datagram came.
One would use recv() either when one doesn't care about that
information, or whenone has called connect() to limit reception to
that one remote IP address/port pair.
> My own experiments show that when polling 100 sockets for incoming
> UDP packets, if I use recvfrom() I get on average almost twice as
> many POLLIN events than when I use recv(). In other words, when I
> use recv(), a lot more packets are lost. So obviously, recvfrom()
> seems to be a lot more reliable when dealing with UDP packets.
They may have different path lengths, which means when trying to
keep-up with flows one might work better than another, but to say that
makes one more "reliable" than another doesn't sound like quite the
correct description.
> However, this is based only on my own observations. I have never
> seen this documented anywhere. Is this effect unique to my OS,
> (Linux 2.6) or is it generally understood that recvfrom() should
> *always* be used with UDP connections?
It depends. I'd probably consult the works of Stevens, Fenner and
Rudoff or perhaps Stallings.
rick jones
--
firebug n, the idiot who tosses a lit cigarette out his car window
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...