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:38:06 -0700
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.
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