MACALLSTR@vax1.physics.oxford.ac.UK (06/22/87)
Where does a LAT terminal server obtain its menmonic/address information for services on the Ethernet other than those situated locally on the terminal server? The Decserver-200 documentation appears only to have commands for defining local services. When a user issues a CONNECT <service> command, where does the T.S. software look for the <service> menomonic to Ethernet address translation? A few possibilities spring to mind. (1) Information is down-line loaded from the load host node when the terminal server is initialised. (2) Each LAT host node sends the information out to all known terminal servers when that node reboots. (4) Information is sent out a regular intervals. (5) The CONNECT command sends a request to the load host and picks up the information from there. The terminal server would cease to function or have to be reloaded if the load host stopped for any reason. (6) If (5), does all terminal server traffic continue through the load host ( surely not ?! ) or as a normal Ethernet broadcast to the particular service? The terminal server would cease to function or have to be reloaded if the load host stopped for any reason. (7) The terminal server monitors all Ethernet traffic and somehow picks up the addresses of live Ethernet nodes AND the node/service mnemonics. Doing this would be a significant overhead if EVERY packet has to be monitored. Perhaps there is some Ethernet LAT documentation which describes this? Enquiries to DEC Software Support suggest that (7) might be the answer. I don't yet have a terminal server to determine, empirically, what the mechanism might be. Does anyone have accurate information on this question? John
LEICHTER-JERRY@YALE.ARPA (06/23/87)
Where does a LAT terminal server obtain its menmonic/address information
for services on the Ethernet other than those situated locally on the
terminal server?...
A few possibilities spring to mind.
(4) Information is sent out a regular intervals.
[I've left out the incorrect possibilities - the author listed 7!]
The model LAT uses is that various nodes "offer services" that a given LAT
terminal server will then allow connections to. The way a node "offers a
service" is to send out multicasts at regular intervals - default is every 20
seconds; this is a settable parameter - describing what services it has to
offer. All terminal servers listen for these multicasts and update their
service/address tables when they something new. (I don't think terminal
servers ever remove a service from their tables until someone tries to connect
to it and the attempt fails, but I might be wrong on this.)
The multicast is a "node configuration message"; it describe such things as
the node's Ethernet address, the services offered, the groups the node is a
member of, and the node's current load rating.
-- Jerry
-------jmg@cernvax.UUCP (jmg) (06/30/87)
In article <8706231009.AA03055@ucbvax.Berkeley.EDU> <LEICHTER-JERRY@YALE.ARPA> writes: >The model LAT uses is that various nodes "offer services" that a given LAT >terminal server will then allow connections to. The way a node "offers a >service" is to send out multicasts at regular intervals - default is every 20 >seconds; this is a settable parameter - describing what services it has to >offer. All terminal servers listen for these multicasts and update their >service/address tables when they something new. (I don't think terminal >servers ever remove a service from their tables until someone tries to connect >to it and the attempt fails, but I might be wrong on this.) This indeed seems true, although the latest default is 60 seconds. In this it falls into the same DECNET philosophy as routing, i.e. put out multicasts all of the time. This is killing to us because of our interlinking Ethernets across communications subnets, rather than a branching structure of repeaters and LAN Bridges, since then every multicast has to be repeated for every Ethernet. If you then consider all the vast numbers of DECNET hello timers (default 15 seconds, but we have increased to 120 seconds), level 1 and 2 routers, LAT multicast, LAN Bridge multicast, LAVC multicast etc. etc. etc., multiplied by the number of nodes (we are around 200) and the number of interlinked Ethernets you begin to see why a large % of our packets are multicast. Personally, all that I want to know is what are the services and nodes which might be available, not whether they were seen as up in the past few seconds/minutes. I presume that if I then try to use them I should rapidly find out if they are not currently available. Based on this type of philosophy almost all of these multicasts would then not be necessary (and for the greater pleasure note that sudden absence of these multicast packets can generate even more multicast traffic as all the routers try to catch up and inform everyone on the new situation). I would be happy to hear from anyone else who also has met this problem of excessive multicasts on a large DECNET.