I was hoping to avoid this route. Not that it would that difficult to implement since it would only be local host that is connecting, so I have control over both the client and server programming. The client side of things would be a perl .cgi routine.
I currently use a system of file reads and file writes with the PID from the .cgi being the key and the file containing the data to work from and output back, but for some things that I want to be faster, the socket method seems to be the way to go. George > -----Original Message----- > From: [email protected] [mailto:u2-users- > [email protected]] On Behalf Of Jeff Schasny > Sent: Friday, August 28, 2009 10:45 AM > To: U2 Users List > Subject: Re: [U2] back to the socket problem.... > > The server process gets a request to run a process from a remote > machine, gets a "next available" port number and sends it back to the > remote process. It then starts up the requested process process passing > then port to it on the command line then. The process on the remote > machine starts up a listener on the port number specified and after > waiting a few seconds for this to be established the process on the > local machine opens a socket to the remote listener on the specified > port. > > Look here: http://www.schasny.com/bp/SOCKET.SERVER > > George Gallen wrote: > > The problem at hand is that you can't pass the client handle obtained > > from the accept() onto another process, then go back and wait for > another > > connection. If you fire off a phantom, it's a new Process, and isn't > able > > to receive the handle from the other process. > > > > Any suggestions? I considered the method of returning a new port > number > > and having the client reconnect on that port, but I'm not ready to go > > that route just yet. > > > > George _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
