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: Terry Lambert <email@hidden>
- Date: Thu, 1 Jun 2006 12:05:59 -0700
It wasn't clear whether or not the UDP port in question was bound to
the multicast address, or the standard address, and I assumed (perhaps
incorrectly) that it was a standard socket.
Multicast does introduce a wrinkle which I did not consider. For
example, your point about the socket is only true if the socket comes
back from the networking code in the kernel each time. My suggestion
of passing an fd around via UNIX domain sockets assumed a single
socket shared by multiple programs.
If the socket is supposed to be multicast, then you'd want the
privileged program to call the networking stack and vend a socket per
process, so they all get to see the multicast stream, instead of using
a single socket with multiple fd's in multiple processes referencing
the same socket through the same fileglob pointer.
If it's multicast, the inability for anyone to open any socket is
probably a bug, isn't it, given the nature of multicast? I just
assumed it wasn't because of the flags being needed for the open...
-- Terry
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:
This email sent to email@hidden