bill@tifsil.UUCP (Bill Stoltz) (02/05/88)
HELP!
I am looking for information on the feasibility of the following
design on Un*x and other operating systems. I need ideas (how to do this
on _____), comments (you must be nuts, neat idea), or suggestions on how
to solve this problem. I also have a very tight schedule, in that I need
this information by the middle of next week (2/10/88), so I can make a
decision by 2/15/88.
We want to make a decision that is not going to hurt us in the future.
If we move this to a new protocols, or a new operating systems will we
still have the basic functionality to continue with the proposed design,
or will we be stuck with this decision forever.
The need:
We have a server application that handles all incoming requests. The
server needs to pass off these requests to another process to complete
the transaction. The data will come in over the network through something
that works like Berkeley Sockets. We are using an internally developed
protocol and we do not have the option of changing any of the requester
code. It may be possible to change the socket code on the Un*x system.
Current design:
The server currently receives data into shared memory, then sends a short
message to the appropriate application telling in where the data is in shared
memory and lets the application process the data.
This is fine for this application, but it is felt that adding this new
functionality to the server would make it a bottleneck, and it would not be
able to handle new requests.
Trying fork/exec:
Using fork/exec was suggested to handle this problem, but this was
quickly rejected. The reasons given are maintainability of all the pieces,
changes the current design, lack of control and coordination if several
of the same functions are requested at the same time.
The designers plan:
The design that is being pushed is to have the server pass off the
connection (socket) to a non-related, already running process to finish
the transaction. The server must read the first part of the data to determine
which application is to receive the connection. The connection must be
passed off to the non-related process without closing the connection.
The application process must be able to continue communications
with very little interaction between itself and the server, except to say
"here is a new connection, you handle it". The server is then out of the
picture. The application then sends down the data and terminates the
connection. This gives them the control they need and does not make the
server a bottleneck.
The problem:
Can I provide this functionality under Un*x?
What do I need to hack to do this?
Is this supported under other socket implementations?
Is this possible on other operating systems?
Is this going to be available in future products?
I have posted this to several boards, so please send your comments by e-mail.
Thanks for any help or comments. The life you save may be mine.
Bill Stoltz
Texas Instruments
Process Automation Center
P.O. Box 655012, M/S 3635
Dallas, TX 75243
UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!bill
DECNET: TIFSIE::bill
Voice: (214) 995-2786larry@pdn.UUCP (Larry Swift) (02/08/88)
In article <291@tifsil.UUCP> bill@tifsil.UUCP (Bill Stoltz) writes: >I have posted this to several boards, so please send your comments by e-mail. Bill, I, and I suspect many others, are interested in any replies you get. Could you post a summary? Larry Swift UUCP: {codas,usfvax2}!pdn!larry Paradyne Corp., LF-207 Phone: (813) 530-8605 P. O. Box 2826 Largo, FL, 34649-9981
jbeard@quintus.UUCP (Jeff Beard) (02/09/88)
Your problem is of interest to anyone concerned with nested servers. I for one would appreciate a posting of the summary of your findings. Tnx.
sklower@sequoia.Berkeley.EDU.berkeley.edu (Keith Sklower) (02/12/88)
In article <633@eden.quintus.UUCP> jbeard@quintus.UUCP (Jeff Beard) writes: > > >Your problem is of interest to anyone concerned with nested servers. >I for one would appreciate a posting of the summary of your findings. > >Tnx. 4.2 and 4.3 BSD provide a means of passing an open file descriptor of any sort (including sockets) between two co-operating processes by means of the sendmsg system call. In fact, I am presently engaged in reducing the latency in providing XNS courier services under UNIX by use of this mechanism. The Courier RPC protocol imbeds requests for services as part of the data of a stream, so one would like to pass the stream between processes, and fork + exec is a relatively slow way to do it. For greatest speed, you want to establish an additional UNIX-domain socket connection between the two processes prior to when the "passing of the baton" will occur. You can do this with either a stream or datagram connection (but if you use a datagram connection you must be careful to check that the sendmsg system call doesn't fail due to lack of buffer space; if it does, don't close the socket you are handing off, but try the sendmsg() system call over again later). Here is a code fragment to send the file descriptor: (You can pass data in addition to the socket, like any excess data you may have drained from it by mistake). pass_fd_rights(s, fd, buf, buflen) int s, fd, buflen; char *buf; { static struct msghdr msg; static struct iovec iov[1]; iov->iov_base = buf; iov->iov_len = buflen; msg.msg_iov = iov; msg.msg_iovlen = 1; msg.msg_accrights = (caddr_t)&fd; msg.msg_accrightslen = sizeof (fd); sendmsg(s, &msg, 0); } recvmsg() is the system call you use to collect the passed file descriptor.
chris@trantor.umd.edu (Chris Torek) (02/12/88)
In article <22952@ucbvax.BERKELEY.EDU> sklower@sequoia.Berkeley.EDU.UUCP ----? (Keith Sklower) writes: >4.2 and 4.3 BSD provide a means of passing an open file descriptor >of any sort (including sockets) between two co-operating processes >by means of the sendmsg system call. Beware, however, of some rather serious bugs in the implementation in 4.2BSD. For instance, using MSG_PEEK with recvmsg() on a message with rights can cause multiple acceptance of the passed file descriptor, resulting in eventual file system corruption (without the closef firewall) or a panic (with the firewall). All of this is fixed in 4.3BSD (with the possible exception of the fd garbage collection code---try not to send pipe descriptors to yourself over those pipe descriptors, please). Which SunOS releases may have which bugs I cannot say. -- In-Real-Life: Chris Torek, Univ of MD Computer Science, +1 301 454 7163 (hiding out on trantor.umd.edu until mimsy is reassembled in its new home) Domain: chris@mimsy.umd.edu Path: not easily reachable