Re: recv() vs recvfrom()
- From: Frank Cusack <fcusack@xxxxxxxxxxx>
- Date: Wed, 30 Jan 2008 10:53:09 -0800
On Wed, 30 Jan 2008 12:31:31 +0100 Syren Baran <sbaran@xxxxxxxxxxxxxxx> wrote:
Frank Cusack schrieb:
On Sun, 27 Jan 2008 03:12:32 +0100 Syren Baran <sbaran@xxxxxxxxxxxxxxx> wrote:
Frank Cusack schrieb:
i have a udp client that uses an ephemeral port. it seems like myplease be slightly more specific here.
server,
Ephemeral only means randomly allocated in a reserved region.
how can i be more specific? ephemeral source port? that goes without
saying.
Maybe i was a bit confused 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 seek 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.
[..]therefore, must use recvfrom() to get packets, since i
can't connect() the socket. is that right?
what does any of that have to do with my question?
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
.
- Follow-Ups:
- Re: recv() vs recvfrom()
- From: Syren Baran
- Re: recv() vs recvfrom()
- References:
- recv() vs recvfrom()
- From: Frank Cusack
- Re: recv() vs recvfrom()
- From: Syren Baran
- Re: recv() vs recvfrom()
- From: Frank Cusack
- Re: recv() vs recvfrom()
- From: Syren Baran
- recv() vs recvfrom()
- Prev by Date: Re: using libjpeg
- Next by Date: Re: recv() vs recvfrom()
- Previous by thread: Re: recv() vs recvfrom()
- Next by thread: Re: recv() vs recvfrom()
- Index(es):
Relevant Pages
|
