site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com 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? - - - -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... On May 31, 2006, at 9:44 PM, Michelle Munson 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. 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. This email sent to site_archiver@lists.apple.com