Home > Archive > Unix Programming > January 2008 > recv() vs recvfrom()
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
recv() vs recvfrom()
|
|
| Frank Cusack 2008-01-23, 7:19 pm |
| i have a udp client that uses an ephemeral port. it seems like my
server, therefore, must use recvfrom() to get packets, since i
can't connect() the socket. is that right?
-frank
| |
| Rick Jones 2008-01-23, 7:19 pm |
| Frank Cusack <fcusack@fcusack.com> wrote:
> i have a udp client that uses an ephemeral port. it seems like my
> server, therefore, must use recvfrom() to get packets, since i
> can't connect() the socket. is that right?
The decision to use recv() vs recvfrom() is based on whether or not
you want to know the source of the datagram.
The decision to use send() vs sendto() is based on whether or not you
have "connect()ed" the socket to the remote destination.
rick jones
--
No need to believe in either side, or any side. There is no cause.
There's only yourself. The belief is in your own precision. - Jobert
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...
| |
| Syren Baran 2008-01-27, 4:34 am |
| Frank Cusack schrieb:
> i have a udp client that uses an ephemeral port. it seems like my
> server,
please be slightly more specific here.
Ephemeral only means randomly allocated in a reserved region.
therefore, must use recvfrom() to get packets, since i
> can't connect() the socket. is that right?
UDP is connectionless.
You only have a port and an adress.
You dont have a "stream" like in tcp.
You have neither a garantee a packet arrives, nor in which order.
In other words you will have to (re-)implement all tcp featuers you need.
Disclaimer:
I have only used tcp so far and intend to use udp.
I have good protocoll knowledge and know "where it can hurt". You´ll
need more than knowledge of some unix functions to code reliable
datagram transfers.
>
> -frank
| |
| Barry Margolin 2008-01-27, 4:34 am |
| In article <479be8a2$0$27200$9b4e6d93@newsspool1.arcor-online.net>,
Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Frank Cusack schrieb:
> please be slightly more specific here.
> Ephemeral only means randomly allocated in a reserved region.
> therefore, must use recvfrom() to get packets, since i
> UDP is connectionless.
But sockets allows you to call connect() on a UDP socket. This has
several effects: 1) You can use send() rather than sendto(), as it knows
the remote address/port; 2) it will only receive packets whose source
address/port are the remote address/port used in connect(); 3) ICMP Port
Unreachable messages about that remote address/port will result in an
error on the socket.
> You only have a port and an adress.
> You dont have a "stream" like in tcp.
> You have neither a garantee a packet arrives, nor in which order.
> In other words you will have to (re-)implement all tcp featuers you need.
What does any of this have to do with his question about recv() vs.
recvfrom()?
>
> Disclaimer:
> I have only used tcp so far and intend to use udp.
> I have good protocoll knowledge and know "where it can hurt". You´ll
> need more than knowledge of some unix functions to code reliable
> datagram transfers.
Who said anything about coding reliable datagram transfers?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Syren Baran 2008-01-27, 8:20 am |
| Barry Margolin schrieb:
>
> What does any of this have to do with his question about recv() vs.
> recvfrom()?
Nothin really, but
> Who said anything about coding reliable datagram transfers?
if you ABSOLUTELY dont care if a packet arrives (no checksum btw, so it
could even arrive in a damaged state!) what's the sense in sending the
packet?
I?m merely advising against the usage of udp UNLESS one has a good
reason to use it (and yes there are a lot of good reasons).
| |
| Rainer Weikusat 2008-01-27, 7:39 pm |
| Syren Baran <sbaran@gmx-dontspam.de> writes:
> Barry Margolin schrieb:
> Nothin really, but
> if you ABSOLUTELY dont care if a packet arrives (no checksum btw, so
> it could even arrive in a damaged state!) what's the sense in sending
> the packet?
The chances that it arrives are quite good (even TCP is basically
unusable for anything but background filetransfers in face of high
packet loss) and a couple of lost packets don't necessarily matter. An
example would be VoIP. UDP datagrams are usually checksummed, except
if requested otherwise. And 'common link layer protocols', ie
'ethernet', do checksumming, too.
| |
| Syren Baran 2008-01-27, 7:39 pm |
| Rainer Weikusat schrieb:
> Syren Baran <sbaran@gmx-dontspam.de> writes:
>
> The chances that it arrives are quite good (even TCP is basically
> unusable for anything but background filetransfers in face of high
> packet loss) and a couple of lost packets don't necessarily matter. An
> example would be VoIP.
Right thats one of the good reasons to use UDP. If timing is more
important than data consistency. No reason to limit it to voip though.
Applies to all error tolerant streamed media.
Another type of application that goes into this "timing is more
important than consistency" are real time games (e.g. every packet is
only "valid" until the next one arrives).
The other main reason to use udp is to avoid the tcp overhead. Often
seen if file sharing programms. This usualy means implementing some form
of checksums.
> UDP datagrams are usually checksummed, except
> if requested otherwise. And 'common link layer protocols', ie
> 'ethernet', do checksumming, too.
Right. But relying on "usually" is not good coding practice, imho.
| |
| Rainer Weikusat 2008-01-27, 7:39 pm |
| Syren Baran <sbaran@gmx-dontspam.de> writes:
> Rainer Weikusat schrieb:
[...]
[color=darkred]
>
> Right. But relying on "usually" is not good coding practice,
> imho.
This means checksumming UDP datagrams is the default behaviour, but
this default behaviour can be disabled. Your statement about lack of
checksumming, as quoted above, is therefore wrong. IPv4 has a separate
header checksum. This has been removed for IPv6 because it is expected
that the link-layer will take care of checksumming, anyway.
| |
| Syren Baran 2008-01-27, 7:39 pm |
| Rainer Weikusat schrieb:
>
> This means checksumming UDP datagrams is the default behaviour, but
> this default behaviour can be disabled.
The protocoll clearly states this checksum is optional.
> Your statement about lack of
> checksumming, as quoted above, is therefore wrong.
You say checksumming is the default behavior. On your box maybe.
However it is optional and a conforming implementation may choose not to
check sum.
Thus you have no garantee an incoming udp packet has a checksum.
> IPv4 has a separate
> header checksum.
Header != data
This has been removed for IPv6 because it is expected
> that the link-layer will take care of checksumming, anyway.
If the link layer is required to checksum thats nice. As long as this
this is not garanteed its a possible error scenario.
| |
| Rainer Weikusat 2008-01-27, 7:39 pm |
| Syren Baran <sbaran@gmx-dontspam.de> writes:
> Rainer Weikusat schrieb:
[color=darkred]
> The protocoll clearly states this checksum is optional.
The 'protocol' cannot 'state' anything about itself. This would be the
protocol specification. Obviously, if a checksum can either be
calculated or not calculated, wether it is to be calculated must be an
option.
[color=darkred]
> You say checksumming is the default behavior. On your box maybe.
> However it is optional and a conforming implementation may choose not
> to check sum.
Please name such an implementation for UNIX(*) with an installed base
of more than three systems. Alternatively, name one (for UNIX(*))
where the default behaviour would be different. You can skip checking
BSD (same default), Solaris (documented as always checksummed) and AIX
(dito).
> Thus you have no garantee an incoming udp packet has a checksum.
You originally wrote about sending datagrams and I replied to
that.
| |
| Syren Baran 2008-01-27, 7:39 pm |
| Rainer Weikusat schrieb:
> Syren Baran <sbaran@gmx-dontspam.de> writes:
>
>
> The 'protocol' cannot 'state' anything about itself. This would be the
> protocol specification. Obviously, if a checksum can either be
> calculated or not calculated, wether it is to be calculated must be an
> option.
And for udp this is an option, unlike tcp where this is required.
>
>
>
> Please name such an implementation for UNIX(*) with an installed base
> of more than three systems.
That would be a waste of time. Am i supposed to check every other OS for
every possible connected device as well?
The checksum is optional. Period.
If you would like to depend on this checksum just because you know three
Unix versions that, by default, generate checksums, do so, i wont.
| |
| Barry Margolin 2008-01-27, 7:39 pm |
| In article <479ce1c8$0$25372$9b4e6d93@newsspool4.arcor-online.net>,
Syren Baran <sbaran@gmx-dontspam.de> wrote:
> That would be a waste of time. Am i supposed to check every other OS for
> every possible connected device as well?
> The checksum is optional. Period.
Do you know of ANY system where checksums are off by default?
Checksums were made optional in UDP when it was first defined because
UDP was expected to be used for applications where simplicity and
performance were more important than safety. But in the 30 years since
then, computer speeds have increased so much that the performance impact
of computing and checking the checksum is negligible. Every implementor
is aware of this, and it's now common practice to use the checksum.
So while it's POSSIBLE that some implementations may not do it, they're
rare enough that no one would use this as a reason to avoid using UDP
when it's otherwise appropriate.
I still don't understand why you brought this up in the first place. No
one asked for your advice on UDP vs. TCP. Are you going to make this
point every time someone asks a question about UDP? Are you on a
cru e to stamp out UDP whenever you get a hint that it's being used?
Did an unchecksummed UDP datagram cause a death in your family?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Syren Baran 2008-01-27, 7:39 pm |
| Barry Margolin schrieb:
>
> Do you know of ANY system where checksums are off by default?
No. Nor did i check.
>
> Checksums were made optional in UDP when it was first defined because
> UDP was expected to be used for applications where simplicity and
> performance were more important than safety. But in the 30 years since
> then, computer speeds have increased so much that the performance impact
^^^^^^^^
> of computing and checking the checksum is negligible. Every implementor
> is aware of this, and it's now common practice to use the checksum.
So you agree that it wasnt common to calculate check sums when the
computing overhead wasnt negligable. Not all devices have 64bit
multi-GHz processors.
>
> So while it's POSSIBLE that some implementations may not do it, they're
> rare enough that no one would use this as a reason to avoid using UDP
> when it's otherwise appropriate.
>
> I still don't understand why you brought this up in the first place. No
> one asked for your advice on UDP vs. TCP. Are you going to make this
> point every time someone asks a question about UDP?
No, and i might have falsely assumed the OP is pretty new to network
coding. UDP can be tricky and i wouldn´t advise its use to a newb, thats
all.
> Are you on a
> crue to stamp out UDP whenever you get a hint that it's being used?
> Did an unchecksummed UDP datagram cause a death in your family?
No, as you may have read i also intend to use udp myself.
You might have also read the examples about udp where its preferable to tcp.
>
| |
| Logan Shaw 2008-01-28, 4:33 am |
| Barry Margolin wrote:
> In article <479ce1c8$0$25372$9b4e6d93@newsspool4.arcor-online.net>,
> Syren Baran <sbaran@gmx-dontspam.de> wrote:
>
>
> Do you know of ANY system where checksums are off by default?
I don't have time to research it, but I have a vague recollection
that UDP checksums were off by default on SunOS 4.1.x. My vague,
and possibly-inaccurate recollection involves noticing how to turn
them on, either by changing kernel configuration or installing
a patch, and also wondering why they weren't on already.
Ah, a quick google turns this up:
http://www.unix.org.ua/gated/node13.html
That has instructions on how to enable them by using "adb -k".
- Logan
| |
| Rick Jones 2008-01-28, 7:24 pm |
| Syren Baran <sbaran@gmx-dontspam.de> wrote:
> You have neither a garantee a packet arrives
Strictly speaking, TCP doesn't make that guarantee either. What TCP
promises is to provide notification of probable non-delivery.
rick jones
--
oxymoron n, commuter in a gas-guzzling luxury SUV with an American flag
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...
| |
| Rick Jones 2008-01-28, 7:24 pm |
| Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> header checksum. This has been removed for IPv6 because it is
> expected that the link-layer will take care of checksumming, anyway.
Gotta love it - something operating end-to-end relying on a hop-by-hop
behaviour. Lots of faith in/by the router guys.
rick jones
--
a wide gulf separates "what if" from "if only"
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...
| |
| Barry Margolin 2008-01-28, 10:19 pm |
| In article <479d7c89$0$17369$4c368faf@roadrunner.com>,
Logan Shaw <lshaw-usenet@austin.rr.com> wrote:
> Barry Margolin wrote:
>
> I don't have time to research it, but I have a vague recollection
> that UDP checksums were off by default on SunOS 4.1.x. My vague,
I remember it as well. Annoying as hell -- we used to get lots of
corrupt NFS data because of it.
But I used the present tense. SunOS 4.1.x hails from the same time
frame as processors that were slow enough that checksum overhead was
non-negligible.
If I were designing network applications, I wouldn't waste much effort
worrying about people running untuned, 15-year-old systems.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Frank Cusack 2008-01-29, 7:26 pm |
| On Sun, 27 Jan 2008 03:12:32 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Frank Cusack schrieb:
> please be slightly more specific here.
> Ephemeral only means randomly allocated in a reserved region.
how can i be more specific? ephemeral source port? that goes without
saying.
> UDP is connectionless.
> You only have a port and an adress.
> You dont have a "stream" like in tcp.
> You have neither a garantee a packet arrives, nor in which order.
> In other words you will have to (re-)implement all tcp featuers you need.
> Disclaimer:
> I have only used tcp so far and intend to use udp.
> I have good protocoll knowledge and know "where it can hurt". You´ll
> need more than knowledge of some unix functions to code reliable
> datagram transfers.
what does any of that have to do with my question?
BTW, please insert blank lines between quoted text and your reply.
Like everyone else does.
-frank
| |
| Barry Margolin 2008-01-30, 4:34 am |
| In article <479f5cfd$0$9103$9b4e6d93@newsspool2.arcor-online.net>,
Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Barry Margolin schrieb:
>
> Maybe i should tell the reason i didnt check. I didnt want to write
> test applications for Symbian, Linux and WindowsCE. Not to mention all
> the propriatary older phone OS´s,e.g. NokiaOS.
I didn't expect you to check. You seemed so worried about it that I
assumed you already knew that there are such systems.
>
> I dont know why, but according the my bit torrent clients statistics the
> hash failure rate for the packets lies around 0.1 - 0.2% (with packets
> varying in size from 128K to 4M), though i do admit that my dsl line
> isnt exactly as good as it should be.
BT uses TCP, not UDP.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Syren Baran 2008-01-30, 8:23 am |
| Frank Cusack schrieb:
> On Sun, 27 Jan 2008 03:12:32 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
>
> how can i be more specific? ephemeral source port? that goes without
> saying.
Maybe i was a bit  because i ate fries, which were made from
potatoes, with ketchup, that was made from tomatoes, and talked to a
person, who breathes air.
I dont know of any clients that *dont* use ephemeral ports.
I was just curious as to what you wanted to do, maybe i, or someone else
here, could give you a tip then.
[..][color=darkred]
> what does any of that have to do with my question?
I prefer defaulting to tcp, ymmv.
>
> BTW, please insert blank lines between quoted text and your reply.
> Like everyone else does.
NP ;)
| |
| Syren Baran 2008-01-30, 8:23 am |
| Barry Margolin schrieb:
>
> BT uses TCP, not UDP.
Weird. Than what does Azureus do with the UDP ports it uses according to
netstat?
I always assumed BT uses tcp for control and udp for bulk data, like the
old donkey.
However the udp packets seem too small to be data (just checked with
Wireshark).
| |
| Frank Cusack 2008-01-30, 7:24 pm |
| On Wed, 30 Jan 2008 12:31:31 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Frank Cusack schrieb:
>
> Maybe i was a bit because i ate fries, which were made from
> potatoes, with ketchup, that was made from tomatoes, and talked to a
> person, who breathes air.
Sorry to ruin your joke :) but I don't get it. You are speaking in
generalities. I was not.
> I dont know of any clients that *dont* use ephemeral ports.
The most common one I can think of is nfs clients.
Another one I can think of is caching dns servers. It's not uncommon
to configure them to use source port 53. This aids when configuring
firewalls (you can disallow other outbound UDP traffic).
I'm sure there are others I know of that are just escaping me.
> I was just curious as to what you wanted to do, maybe i, or someone
> else here, could give you a tip then.
Ah, well maybe you should have asked that then, rather than define
ephemeral.
There doesn't seem to be a language barrier, otherwise I'd say maybe
"more specific" isn't what you meant to say.
In my case I had a multithreaded client with a single communication
thread. All work was queued and the comm thread picked up the work
and made requests to the server over a single socket with a fixed
source port. This allowed me to use read()/write() (recv()/send()) on
both client and server, but meant my client had to multiplex and
demultiplex requests.
I changed the design of my client and it was much simpler to eliminate
that comm thread. Now each piece of "work" is handled entirely in a
single thread and I cannot use a single source port anymore, as I'd
have no way to get the reply packets to the proper thread.
On the face of it, my design change would now elicit lots of advice
about how thread-per-request is a bad choice yadda yadda but I am
leaving a lot out which would justify it. It would take too long to
describe and it's not worthwhile since I do not s advice on it.
My question was based on my server now being less efficient (sendto()
vs send(), when the other endpoints are a small, fixed, preconfigured
set of hosts). I zoomed in the wrong part of the problem (recv() vs
recvfrom()) but in any case, Rick managed to answer my question
quickly, succinctly and completely.
> [..]
>
> I prefer defaulting to tcp, ymmv.
That doesn't really answer my question (I think the correct answer
here is "nothing"), but anyway I prefer not to default to any
protocol. I choose based on my requirements.
-frank
| |
| Syren Baran 2008-01-30, 7:24 pm |
| Frank Cusack schrieb:
> I changed the design of my client and it was much simpler to eliminate
> that comm thread. Now each piece of "work" is handled entirely in a
> single thread and I cannot use a single source port anymore, as I'd
> have no way to get the reply packets to the proper thread.
Buffer+polling, e.g.
struct{
int id;
char* data;
}packet;
The reader fills an array of such structs. The worker threads periodicly
check for new data, based on id.
Dont know if its usefull in your case, though.
| |
| Frank Cusack 2008-01-30, 7:24 pm |
| On Wed, 30 Jan 2008 20:59:52 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Frank Cusack schrieb:
>
>
> Buffer+polling, e.g.
> struct{
> int id;
> char* data;
> }packet;
> The reader fills an array of such structs. The worker threads
> periodicly check for new data, based on id.
Of course. Something similar was my previous design.
-frank
| |
| Syren Baran 2008-01-30, 7:24 pm |
| Frank Cusack schrieb:
> On Wed, 30 Jan 2008 20:59:52 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
>
> Of course. Something similar was my previous design.
Mind to tell why you changed it?
I was thinking about using that approach.
>
> -frank
| |
| Frank Cusack 2008-01-30, 10:24 pm |
| On Wed, 30 Jan 2008 21:45:35 +0100 Syren Baran <sbaran@gmx-dontspam.de> wrote:
> Frank Cusack schrieb:
>
> Mind to tell why you changed it?
Unrelated to the goodness of the worker thread / work queue design.
For example, my server still uses this design. It just no longer
makes sense in the client because the way the client gets its input is
now limited to thread-per-request. Putting work into a queue for
handling by a thread pool is now actually more work.
-frank
| |
| Logan Shaw 2008-01-31, 4:33 am |
| Syren Baran wrote:
> Barry Margolin schrieb:
[color=darkred]
> Weird. Than what does Azureus do with the UDP ports it uses according to
> netstat?
> I always assumed BT uses tcp for control and udp for bulk data, like the
> old donkey.
> However the udp packets seem too small to be data (just checked with
> Wireshark).
The info I can find says that true BitTorrent doesn't use UDP at all.
I suspect there is some extension that uses UDP, and the logical thing
to use it for would be exchanging data with a tracker, so that you can
easily send/receive periodic updates about which peers are available
and stuff like that.
- Logan
|
|
|
|
|