Greg -- I am not sure I understand the problem. If the client does not shut down "cleanly" there are two cases to consider:
(a) The server's TCP connection goes away. This will cause the server process to shut down cleanly. (b) The server's side of the TCP connection somehow remains and doesn't go away. In this case, with a dead client the server process remains, occupying a slot in the process table, and few square millibleems on disk to where its memory gets paged, where it stays until the computer gets shut down or it gets purged. So, implementing via [x]inetd and TCP would seem to be just fine. -- Bhaskar On Fri, 2006-01-06 at 13:11 -0600, Gregory Woodhouse wrote: > > On Jan 6, 2006, at 10:22 AM, Marc Krawitz wrote: > > > Listener is still running. I am running FOIA20051021. > > Unfortunately, I cannot re-create the error message I received at > > home (now connecting remotely from work). When I get home, I'll > > provide the exact error message. > > > > --Marc > > > Are you sure? The test Nancy recommended will only tell you if SOME > process is listening on the given port. There are a few > complications > here: For one, [x]inetd works by listening for connections on a > number of ports. When it accepts a connection, it forks off a > process > to run the appropriate "handler" (in our case, a MUMPS process) and > then it leaves the picture. In many cases, all the "handler" does > is > read a request, send a reply, and then exit. That's it. But the RPC > Broker is different, it is sets up a single connection that can be > used for a potentially unbounded number of requests (RPCs) though a > series of interactions with the same client (much like telnet, SMTP > or HTTP/1.1). If the client does not shut down cleanly, the > "handler" > will eventually time out, but how long does it wait? (As an aside: > this is not the only possible architecture, and perhaps not the > ideal > one. An alternative would be to use "sessions" for one RPC only, > presumably with some type of a token for authentication and context > management. On a LAN, at least, I think using UDP would be > preferable, too, but for some reason, MUMPS implementations rarely, > if ever, seem to provide UDP support.) I looked at the code, and > the > Broker listeners are shut down by sending special requests to the > appropriate port using the loopback address. So, attempting to shut > down will always "work", even if it doesn't do anything (except > maybe > wake up the Broker)! > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "Good acts are like good poems. One may easily get their drift, but > they are not rationally understood." > --Albert Einstein ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
