|
HP OpenVMS Systemsask the wizard |
|
The Question is: Hi, I have written a utility in Fortran which can send multiple DCL commands to multiple VMS nodes over DECnet, execute the commands on the remote systems, and collate, present and navigate the command output on the controlling node. This uses DECnet task-to-task communication, ASTs and parallel processing to deliver the goods very quickly indeed. It is a fabulous tool for managing multiple networked VMS systems. Unfortunately, DECnet is going out of fashion, so I need to extend my utility to use TCP/IP. What is nice about DECnet is that its server processes don't die after you disconnect - they can be re-used a bit later, without having to go through the login process. This doesn't seem to happen under TCP/IP and I have reached the conclusion I need to write my own ACP to emulate what occurs under DECnet, including access control and proxy look-up. I have done some experimental TCP/IP programming following the documentation and example client and server programs provided with the TCP/IP Services software. I am again using Fortran and the System Services interface to do this. This works fine, in that my server program sets up its listener socket, accepts connections from remote clients and communicates with them over the network. However, there seems to be an undesirable effect which is apparently outside my control: When my server program has finished with a communication socket, which it closes and deletes, the socket doesn't disappear immediately. It seems to hang around for another 30 seconds after the $DASSGN call and then disappears. This presumably happens under control of the Internet driver. If I enter the UCX$UCP utility ($ UCX), I can see these "sockets in limbo" occupying small dynamic buffers, by using the SHOW COMMUNICATION/MEMORY/CONTINUOUS command. The test harness I have written for my ACP sets up lots of TCP/IP connections to the server as fast as possible - as might happen in real life under heavy loads. The effect of these sockets in limbo is that they accumulate until all socket resources have been used, at which point, the server program hangs. The client and server processes go into a LEF state until some of the limbo sockets pass their 30 second timeout, at which point the processes resume. The Internet driver doesn't seem to re-use these sockets in limbo. If a local client tries to set up a connection to the server when all sockets have been used, the client bombs out with an INSFMEM error. If I put LIB$WAIT calls in my server program such that it never uses all available sockets it runs continuously, without these hang-ups (albeit slowy). What I would like to happen is that either the Internet driver re-uses these sockets in limbo, or zaps them immediately, but this "slow death" effect is a real show stopper as far as my ACP is concerned. I have tried playing with all the likely looking $QIO function modifiers from within my ACP and also tried adjusting parameters within UCX$UCP. The only thing which has had any effect so far is increasing the number of device sockets and small buffers available system-wide. This is not a solution though, as my ACP just grabs them and then hangs for another 30 seconds. I want my ACP to be capable of handling everything I throw at it, as that is how I intend to use it. I don't mind having a gradual slow-down under load, but having the ACP absorb all available socket resources and then hang for 30 seconds is unacceptable behaviour. What can I do about this? Is there a way of influencing or preventing these sockets in limbo? Versions: VMS 7.1 Alpha, TCP/IP Services for OpenVMS Alpha Version 4.1 (I know these aren't the latest versions, but I want my code to work with real-life VMS systems, ie, VAX and Alpha, many different software versions, some of them quite old.) Dave Jakeman The Answer is : DECnet-Plus over IP is one potential approach here, as is coding with the IP auxillary server and/or a site-specific IP service. Socket timeouts (and reuse) have been discussed before here in the Ask The Wizard area.
|