Re: udp port sharing across processes on OS X?
Re: udp port sharing across processes on OS X?
- Subject: Re: udp port sharing across processes on OS X?
- From: Josh Graessley <email@hidden>
- Date: Thu, 1 Jun 2006 11:42:12 -0700
I missed one other point. If the UDP socket is connected, the stack
will use both the source and destination addresses and port to locate
the socket.
-josh
On Jun 1, 2006, at 11:38 AM, Josh Graessley wrote:
Actually, each socket has it's own receive buffer. The stack will
only deliver unicast packets to the first socket that matches based
on destination address and port. The definition of the "first
socket that matches" is a little vague. On Mac OS X, this is the
first socket bound to the port. This is very implementation
specific. For multicast packets, the stack goes out of its way to
deliver a copy of the packet to every socket.
-josh
On Jun 1, 2006, at 11:09 AM, Terry Lambert wrote:
I see from your email address that you work for Asperasoft, makers
of FASP, which uses UDP instead of TCP for large file transfers
over high latency/packet loss links to avoid the bandwidth delay
product issue, having to support huge TCP windows, or having to
implement rate based ACK or TCP rate halving (e.g. CMU's
experimental replacement for Nagle et. al.) in the native
networking stack of the OS you are running on.
With that in mind, I have to question the validity of doing this
as multiple users. I can understand wanting to do this on "this
is the machine" basis, but on a per-user basis, the only valid
reason for this would be transmission; there's no guarantee that
any given packet would end up going to the right user process on
receive, since only the address of the socket differentiates
inbound packets to the UDP stack: there'd only be one socket
receive buffer associated with it, and whoever read first would
get the data, which is probably not what you want, if you're
trying to use different user identities to do privilege separation
to avoid disclosure of one user's packet contents to another user.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40apple.com
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden