Xref: utzoo comp.protocols.tcp-ip:2426 comp.protocols.misc:217 comp.protocols.iso:30 comp.protocols.ibm:76 comp.unix.questions:5451 comp.dcom.lans:1007 comp.os.vms:4442
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!homxb!whuts!mtune!codas!killer!pollux!ti-csl!tifsil!bill
From: bill@tifsil.UUCP (Bill Stoltz)
Newsgroups: comp.protocols.tcp-ip,comp.protocols.misc,comp.protocols.iso,comp.protocols.ibm,comp.unix.questions,comp.dcom.lans,comp.os.vms
Subject: Pass an open socket to another process????
Keywords: sockets
Message-ID: <291@tifsil.UUCP>
Date: 4 Feb 88 18:51:34 GMT
Organization: TI Process Automation Center, Dallas Texas
Lines: 81



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-2786