The main benefit of using sockets is to have a single point of access from the client side and the ability to implement ACLs by IP and port. If you can queue your requests via file and perform multiplexed reads/writes using a pool of phantoms, then you can actually handle higher throughput for requests. You also don't have the network resources to contend with. If you are using *nix consider creating a tmpfs mount and do your transactions there instead of a disk location. You'll be surprised at how fast you can do I/O with a tmpfs compared to socket services. If you have to have sockets, consider dumping the requests and reading the responses using inetd/xinetd and a standard I/O script. This is similar to how MVWWW does HTTP request/response spooling.
http://mvwww.sourceforge.net ---------------------------------------- Glen Batchelor IT Director All-Spec Industries phone: (910) 332-0424 fax: (910) 763-5664 E-mail: [email protected] Web: http://www.all-spec.com Blog: http://blog.all-spec.com ---------------------------------------- > -----Original Message----- > From: [email protected] [mailto:u2-users- > [email protected]] On Behalf Of George Gallen > Sent: Friday, August 28, 2009 10:59 AM > To: U2 Users List > Subject: Re: [U2] back to the socket problem.... > > 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 _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
