Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcvax!cernvax!jmg From: jmg@cernvax.UUCP (jmg) Newsgroups: comp.os.vms Subject: Re: Ethernet LAT-Decserver-200 query : how is mnemonic/address info obtained? Message-ID: <496@cernvax.UUCP> Date: Tue, 30-Jun-87 07:03:47 EDT Article-I.D.: cernvax.496 Posted: Tue Jun 30 07:03:47 1987 Date-Received: Thu, 2-Jul-87 03:05:00 EDT References: <8706231009.AA03055@ucbvax.Berkeley.EDU> Reply-To: jmg@cernvax.UUCP () Distribution: world Organization: CERN European Laboratory for Particle Physics, CH-1211 Geneva, Switzerland Lines: 33 In article <8706231009.AA03055@ucbvax.Berkeley.EDU> 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.