From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 4 Dec 2009 23:47:39 -0500 To: 9fans@9fans.net Message-ID: <45bb8a0916edcb2ee86883ebeea8945e@brasstown.quanstro.net> In-Reply-To: <> References: <> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] ideas for helpful system io functions Topicbox-Message-UUID: a815286e-ead5-11e9-9d60-3106f5b1d025 On Fri Dec 4 22:39:59 EST 2009, lyndon@orthanc.ca wrote: > > Another example, a little server that allows connections on a single port 443 > > for https and ssh. Ideally after reading the "GET" or ssh banner, it can just > > exec whichever server is needed (or fork and exec something like netcat). but > > in fact due to this "already read some data" problem, it has to stay alive and > > copy the data in and out from the other server. > > It shouldn't be too difficult to write a device that allows file > descriptors to be passed from one process to another. > > The functionality is quite useful. BSD has supported this since the dawn > of time (SCM_RIGHTS), and I have used it in a few commercial network > server products over the years. (Later System Vs have it as well, and > Solaris supports it through their "doors" API. Stevens Vol. 2 describes > the various APIs.) the standard way of passing file descriptors is by fork/exec. this allows security is handled by the normal means. this case would be handled by fork/exec. the general case is handled by srv(3). no sockets need apply. - erik