Beautiful Dave, thanks for the clarification. I can remember running into that problem some months back. Socket's are good.
Am I correct in assuming that one would have two choices here since there is no daemon process to run. 1. Run/spawn a gtm/mumps process through xinetd/inetd (Is this what is referred to as a new style listener in listener configuration?) 2. Run a RPClistener (old style) On Tuesday 21 June 2005 16:07, [EMAIL PROTECTED] wrote: > The old way involved having a listener running on a known port, > which would job off a new MUMPS process for each CPRS client. > > Since the new MUMPS process created a new TCP/IP outgoing socket from > the server, the listener only had a minimal load per CPRS client, and > thus didn't have to hand off the socket (which is not in the MUMPS > standard) nor did it have to start a new listener on the known port, (with > the potential of missing a CPRS client connection) when the new listener > was "taking over". > > Unfortunately, the old method didn't work when connecting a CPRS client > within a NAT or router to a server that also could be within a NAT or > router. Since the CPRS client machine had a non-routeable > address in that case, it was the equivalent of trying to contact someone by > phone where you had their phone extension, but not the main trunk number. > > The new CPRS process follows the idea that if you can get a socket between > the CPRS client and the server, you should simply use that socket. The > expectation is that using inetd/xinetd to handle known port management > would yield no "dropped connections". > > Unfortunately, I don't know the details on how to connect to the new > > CPRS GUI, but I know that it works with a GT.M server deployed under > > inetd/xinetd, but hopefully someone on this list will be able to tell > > you how. > > > > I also don't know why the protocol was changed/enhanced. > > > > -- Bhaskar > > > > Mark Street wrote: > > > I understand. Can you explain some details/mechanism on the new > > > 'direct connect' CPRS GUI. > > > > > > Am I assuming that the 'new way' is to make a direct connection to > > > GT.M/VistA > > > using a superserver connection instead of having RPCBroker listener. > > > Did this grow out of limitations of RPCBroker? -- Mark Street, RHCE http://www.oswizards.com -- Key fingerprint = 3949 39E4 6317 7C3C 023E 2B1F 6FB3 06E7 D109 56C0 GPG key http://www.oswizards.com/pubkey.asc ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
