reggers@uwovax.uwo.ca (Reg Quinton) (07/19/88)
I'm having a problem with Decnet and am looking for anyone with similar experiences (and even solutions!). Here's the problem and what I've been able to figure out. I've got a daemon process who runs (theoretically) until the machine drops -- it's our mail-daemon. The daemon transfers messages to similar daemons on other machines using transparent Decnet access (ie. fopen, fputs, fclose, and so on -- all stdio.h nothing fancy). They talk to one another using SMTP. In the usual course of events the client (my long-running daemon) connects to a server (the decnet object on the remote machine); they talk back and forth; and finally close the decnet link. However, occassionally the client may have to drop the link prematurely (the usual case is the server doesn't answer within a certain time-out period). The server ultimately recognizes there's no one there any more and dies. Here's the rub. a) On the client machine the daemon has closed the link and gone on to do other work (it's certainly NOT hung in any wait state). b) On the server machine the server has finished execution and also closed the link (it's long gone). c) On the server machine ncp:"show known links" shows no links (as it should) in place between the two processes. d) On the client machine ncp:"show known links" shows a Decnet link still in place between client process (which is still running and has gone on to do other work after the close) and the server process (which doesn't even exist). This is a particularly nasty situation for we ultimately run out of Decnet links which, so far as I can tell, aren't really attached to anyone! The links do disappear if we kill the running daemon (ncp says they're attached to him) but this isn't a satisfactory solution. If anyone is aware of this problem, knows a work-around, etc. please get in touch with me by E-mail at any of the following addresses. as always, thanks ---- Telephone: (519) 661 2151 x6026 (a real person and not a machine) Canada: reggers@uwo.ca (used to be UWO.CDN) BITNET: reggers@uwovax.BITNET (for the ethnocentric) UUCP: reggers@julian.UUCP (...!watmath!julian..)
gregory@BRL-LVAX.ARPA ("Daniel L. Gregory") (08/03/88)
Reg Quinton, Message-Id: <507@uwovax.uwo.ca> writes (edited):
I've got a daemon process who runs (theoretically) until the
machine drops -- it's our mail-daemon. The daemon transfers
In the usual course of events the client (my long-running
daemon) connects to a server (the decnet object on the
remote machine); they talk back and forth; and finally close
the decnet link. However, occassionally the client may have
a) On the client machine the daemon has closed the
link
b) On the server machine the server has finished execution and
also closed the link (it's long gone).
d) On the client machine ncp:"show known links" shows a Decnet link
still in place between client process (which is still
This is a particularly nasty situation for we ultimately run
out of Decnet links which, so far as I can tell, aren't
really attached to anyone!
from the networking guide (vms) pg. 2-41:
(some stuff not included)
Then, when the logical link is disconnected, the "object" program (such
as FAL) terminates, but the process is not deleted. Instead, control returns
to the NETSERVER.EXE program, which asks NETACP for another incoming logical
link request to process. This cycle continues until NETSERVER is
deleted after a specified time limit. The default is 5 minutes. To use
a different default time limit, specify the logical name
NETSERVER$TIMEOUT, using an equivalence string in the standard VAX/VMS
"delta time" format: dddd hh:mm:ss.cc
The effect of NETSERVER is to reuse network server processes for more than
one logical link request, eliminating the overhead of process creation for an
often-used node.
---------------------
Hope this helps,
Dan
--------------------------------------------------------------------------------
| Dan Gregory | Director, US Army Ballistic Research Laboratory |
| Systems Manager | ATTN: SLCBR-LF-A (Mr. D.L. Gregory) |
| GREGORY@BRL-LVAX.ARPA | Kent Building (120) |
| (301) 278-3485 | Aberdeen Proving Ground, MD 21005-5066 |
--------------------------------------------------------------------------------
------