Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!emory!gatech!usenet.ins.cwru.edu!eagle!osprey.lerc.nasa.gov!xxseub
From: xxseub@osprey.lerc.nasa.gov (Steven Eubanks)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: PC Remote control software over the Internet
Keywords: NetBIOS
Message-ID: <1991May23.092811@osprey.lerc.nasa.gov>
Date: 23 May 91 13:28:11 GMT
References: <9105180125.AA02886@ftp.com> <9105201435.AA01612@hns.com>
Sender: news@eagle.lerc.nasa.gov
Reply-To: xxseub@osprey.lerc.nasa.gov (Steven Eubanks)
Organization: NASA Lewis Research Center
Lines: 53

In article <9105201435.AA01612@hns.com>, c_bstratton@HNS.COM (Bob
Stratton) writes:
|> 
|>    Date: Fri, 17 May 91 21:25:01 -0400
|>    From: leo j mclaughlin iii <ljm@ftp.com>
|> 
|>    NetBIOS LAN version of CloseUP/Carbon Copy and a vendor of NetBIOS
|> over
|>    TCP/IP which supports M/P-node or extended B-node services.  Stir
|> gently and

stuff deleted.

|> 
|> Would you be so kind as to explain why the NetBIOS implementation
|> style (m/p vs b node) is important. I've read the RFC's, but I'm not
|> clear as to which services you're depending on. (Especially in the
|> extended B-node case.)
|> 

I'm not sure I can speak to the extended B-node case, but B-node
requires all clients of a NetBIOS server (both ends of a CloseUP/Carbon
Copy session) to be
contained within a single LAN.  B-node dependent
services/implementations will 
not operate across an extended LAN which merely routes.  Bridging
(perhaps
via bridging routers ) would be required to support this functionality. 
RFCs
1001/1002 do include mechanisms to support NetBIOS across routed LANs
via
M/P-node support, but: 1) either the potential user market is not [yet
:-)] large
enough for the vendor community to merit the development effort, 2)
NetBIOS-based
LANs are typically being "bridged", or 3) there are enough unresolved
issues
in the RFCs to make interoperability between vendors a sticky issue;
that to
the best of my knowledge, the available M/P-node based product offerings
are
underwhelming or virtually non-existant.  Maybe the problem stems from
all three.

I'm sure that's more than you asked for.... oh well.

Steve
-- 
Steven W. Eubanks,  Telecomm & Networking 	NASA Lewis Research Center
Internet:xxseub@osprey.lerc.nasa.gov		21000 Brookpark Rd. 
(216)433-9479					Cleveland, OH  44135
Disclaimer:  Opinions like mileage, may vary.
"For every complex problem there's a simple solution, and it's usually wrong...