[comp.os.vms] Problems with LAVC's in a LARGE network...

CLAYTON@XRT.UPENN.EDU ("Clayton, Paul D.") (05/21/88)

Curt Bemis, Jr. asked about getting information flowing on LAVC's in a large 
network, with the following article (which has been shortened).

		I see a potential problem with the use of Local Area VaX 
	Clusters, LAVC, in a relatively large Local Broadcasting Network,
	say 300-400 nodes distributed in 4 or 5 DECnet Areas.  
		.
		.
		.
		The LAVC Multicasts are easily partioned in a multi-segment
	LAN environment by "Blocking" the unique LAVC Multicast at that
	segments LAN Bridge-100 (or any other smart bridge).  The Routing
	layer Multicasts cannot be blocked because DECnet must stay alive.
	
		Can "we" get a discussion going about LAVC and the problems
	(or absence of problems) as I have indicated above???


The question revolved around the ability to apparently 'distribute' the nodes 
in a LAVC over a considerable distance on the Enet. Curt mentions the ability 
of the LANbridges to 'block' various types of 'messages' from the various 
segments on the Enet and that the result is a 'broken' LAVC in some cases.

This is a VERY true and correct statement. If the bridges are set to block the 
LAVC multicasts, the nodes will not be functional at all.

There is an EVEN MORE important item to note with LAVC's and their placement on 
a LARGE LAN. There is a TIME limit on how long to wait for an answer to a 
request sent out from a node in a LAVC over the Enet. In point of fact, there 
is two time limits. The first is a three second wait, when everything is 
normal, and the second limit is two seconds, when the node 'thinks' there may 
be a problem getting in contact with another node on the Enet. These times are 
sufficient to use on an Enet which has no bridges on it and therefore has the 
full 10MB bandwidth. The item to WATCH out for is having a bridge between 
nodes in a LAVC that does not pass data at the 10MB rate, or close to it. 
The result if this is not done is a considerable amount of 'Connection lost' 
messages and/or hung nodes.

Hope this helps some. :-)

pdc

Paul D. Clayton 
Address - CLAYTON%XRT@CIS.UPENN.EDU

Disclaimer:  All thoughts and statements here are my own and NOT those of my 
employer, and are also not based on, or contain, restricted information.