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 11:09:26 -0700
On May 31, 2006, at 9:44 PM, Michelle Munson wrote:
By setting the socket options SO_REUSEADDR and
SO_REUSEPORT, I've been able to successfully get two
instances of the same process running as the same user
to bind and share the same UDP port on OS X. However,
if the two instances of the process are running as
different user ids, the bind attempt by the second
instance of the process fails with "address already in
use". Does anyone know if there is way to get two
instances of the same process running as different
user ids to reuse the same UDP port on Mac OS X?
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.
-
If this is specifically for transmission only, then the way to do it
is to open the descriptor from a privileged process, and have your
other processes request a copy of the descriptor, and pass this to the
requesting process from the privileged process over a UNIX domain
socket using standard descriptor passing techniques. This would allow
multiple users to have access to the socket, even though their UIDs
differed. I would strongly encourage you to use a single
multithreaded program rather than multiple programs t keep the
transmission data rate up (by interleaving I/O, either by
multithreading or by using aio), rather than sharing the socket
between programs.
-
If the intent is receipt, and you are guaranteed that inbound packets
will have in-band stream identifying data, then what it sounds like is
that you are actually attempting to implement the moral equivalent of
a streams MUX on MacOS X. If this is the case, then there are a
couple of approaches:
(1) Instead of trying to share the port, have a single user space
process act as the MUX, and push the data to other user space
processes through an IPC mechanism. If necessary, you could make that
mechanism something less efficient, like individual UNIX domain
sockets, or a loopback socket, to make it look more like a socket to a
MUX getting the right data from the MUX. Otherwise, my recommendation
would be to use shared memory to buffer the data in user space, and
deal with it that way (to avoid copying the data back into the kernel
and then back into user space, just to make it look like/be socket
data).
(2) It's somewhat possible to implement a real MUX using a KEXT and
the socket filter API; this would let you intercept inbound packets
and redispatch them to the appropriate user space process. Writing
this beast would be rather complicated, but it would be doable. An
alternate implementation might be to take the "tun" device driver from
one of the BSDs, and modify it; there are several publically available
ports forr the device to MacOS X, which are usually associated with
OpenSource VPN software for MacOS X.
-
In any case, if this doesn't answer your questions, you may want to
tell us more about what you are actually trying to accomplish, and the
people on this list will probably be able to come up with a better way
of solving the actual problem than trying to share UDP sockets between
users.
-- Terry
_______________________________________________
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