I've done a lot of work with socket-based communications over the years. The bottom line is that you simply can't do this directly with MV platforms. Not only is it technically not possible to hand off socket handles, but for licensing purposes most of the MV DBMS vendors frown upon such usage of their licenses. IBM in particular has strong language against this. (Proper/equitable/legal/logical license management is another topic.)
Technically, no, you cannot accept a connection and pass the handle to another process, then respond back to that handle from the other process. If you pass the handle, it's just a number to another process, not a "handle" for an open socket. You also can't close the inbound connection and then re-open it. I've also done the "reconnect on another port" thing and it's not efficient. However, doing this indirectly, your socket listener process can create a pool of the socket handles that it accepts, pass a request as-data (not as a "socket connection") to another process for handling, and then this same server process can return the results to the client through the open socket handle which has not been closed. You need to do basic message passing between processes. The simplest way to do this is to write items to a file and have phantoms waiting to remove these trigger items from the pool to process them. When the phantom is done, it writes a response record. The socket server is not only listening for inbound connections (unblocked) but it's also checking the transaction file for responses. The socket server has to do a logical timeout to avoid waiting too long for a response from a phantom - this timeout must of course be less than the maximum time for which the client will wait for a response. Just like I documented in my blog yesterday in response to the inquiry about TAPI, this demonstrates a separation of tiers, where the comms process does nothing but comms and the data handling processes do nothing but handle data. It works very well if you just employ the pattern. One of the benefits of the above scenario, for example, is that you can code your socket clients and server process(es) to gracefully handle situations where any one or more processes die unexpectedly. Since responses are written to disk they aren't lost, so if a client doesn't get their response they can simply re-request the response using a unique token and they should be able to get their response back from another server process without the response needing to be re-generated. Specific applications won't use this of course, but it's good for some, and not possible if you're forking off a lot of processes that only operate in memory. You can also use the above scenario to return a receipt of sorts to the client, tell a phantom to go process the request, and have the client poll for responses. (Think of this like you're dropping laundry off at the dry cleaners and getting a ticket so that you can come back and pick up your stuff.) This way you don't need to keep connections open. This is similar to the "come back on another port" concept but it eliminates the need for multiple socket servers. Personally, I prefer to completely avoid writing socket interfaces anymore. Better solutions are available these days, allowing us to spend more time on applications than communications interfaces. Again of course, specific apps may require custom interfaces. I just advise against long-term development to save a couple bucks and/or for the coolness factor. HTH Tony Gravagno Nebula Research and Development TG@ remove.pleaseNebula-RnD.com Nebula R&D sells mv.NET and other Pick/MultiValue products worldwide, and provides related development services nospamNebula-RnD.com/products/mvdotnet remove.pleaseNebula-RnD.com/blog Visit PickWiki.com! Contribute! > From: George Gallen > 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. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
