From: MERC::"uunet!WKUVX1.BITNET!MacroMan" 28-APR-1993 02:22:04.72 To: MACRO32@WKUVX1.BITNET CC: Subj: RE: Using local node name in task specification In article <1993Apr26.204754.1@cc.curtin.edu.au>, zrepachol@cc.curtin.edu.au (Paul Repacholi) writes: >When a 0:: request is issued, it is turned into a request to and >passed to ecl. ECL consulte the routing data base and finds n+1 lines it can >use. The extra one is to bounce it back up the stack, 0 hops, and a line cost, >since none is used of 0. ANY other line circuit will reqire at least 1 hop, >and a >0 line cost. A lne to another machine will requre 2 hops min ( one out, >one back ) and the lne cost you have set on the line, plus the line cost of >the lowest cost line on the other machine to you. A quibble -- you've described the results (outside circuits aren't used), but the method is quite different from that. NSP (it's only called the End Communication Layer externally) doesn't consult the routing data base, at least not the list of reachable nodes and circuits and hops and costs thereto. Indeed, NSP has no knowledge of (most of) the routing database, and wouldn't know where to look for this info if its life depended on it. Normally it simply hands packets to the routing layer, with source and destination addresses and logical link numbers, and the routing layer figures it out from there. AT the routing layer, there are indeed entries in the cost and hops tables for the "circuit to the local node", showing zero cost and hops. And if the routing layer was ever asked by NSP on the local node to deliver data to the local node, it would indeed find these entries and do the right thing.... ...Maybe. It hasn't been tested lately, because "i/o" to logical links that terminate on the local node doesn't get that far. Those entries in the routing data base are there not so much for support of the "logical links to the local node" stunt, but rather to get the routing algorithm started -- every router knows one node that it can reach -- itself. So, how are logical links to the local node handled? At link setup time (connect initiate), NSP looks in the RCB to find out if the destination node address is the same as the local node's address, or the same as the local alias address. If so, it sets a flag in the XWB so that other NSP code can conveniently find this out. (XWB$V_STS_LOCAL in XWB$L_STS. The XWB is of course found via the WCB pointer in the CCB.) In the "write" path, at least, there is a small amount of special-case code in NETDRIVER to handle such links; the main difference is that buffer copies through nonpaged pool are avoided for writes to such a link -- the writer's buffer is double-mapped into system address space and NETDRIVER simply MOVCs from there. (This has caused problems for some applications designers who came to depend on the observed fact that writes to logical links going to other nodes are buffered I/O...) I don't know if reads to the local node are handled similarly or not. It seems that it ought to be possible to set up the read IRP with a special _PID pointer to a routine that in turn supplies a special SKAST for I/O completion... which SKAST would simply MOVC from the system-space map of the writer's buffer straight to the read buffer in process space... I don't know if it's done that way though. --- Jamie Hanrahan, Kernel Mode Systems, San Diego CA drivers, internals, networks, applications, and training for VMS and Windows NT uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and Chair, Programming and Internals Working Group, U.S. DECUS VMS Systems SIG Internet: jeh@cmkrnl.com Uucp: uunet!cmkrnl!jeh CIS: 74140,2055