[net.micro.att] 3Bnet

david@uwvax.UUCP (David Parter) (05/25/85)

[talking about problems with 3b2's...]
> These machines are all configured as:
> 
>      2 mb main memory
>      32 mb hard disk
>      1 ports board (4 serials + parallel)
>      1 3bnet board
> -- 
> --- David Herron

can you, or anyone else, tell me about 3bnet?  We are suppossed to 
get it for our 3b2's, and i would like some advance warning of what 
it really is, and what it can talk to. Plus the usual, how hard was
it to install, does it cause problems, etc.

thanks,

david
-- 
david parter
UWisc Systems Lab

...!{allegra,harvard,ihnp4,seismo}!uwvax!david
david@wisc-rsch.arpa

cwd@cuae2.UUCP (Chris Donahue) (05/29/85)

> can you, or anyone else, tell me about 3bnet?
> david parter
> UWisc Systems Lab
> 

3BNET is an Ethernet compatible local area network for the AT&T 3B Computer
Family. 3BNET is supported on the 3B20S, 3B20A, 3B5 family, and 3B2/300
computers. The transmission rate is 10Mbps over a baseband coax cable media
using CSMA/CD as the transmission algorithm. The network can be 500 meters
end-to-end if thick Ethernet cable is used (in multiples of 2.5 meters
between transceivers) or 400 meters end-to-end if thin Ethernet cable is used
(in multiples of 1 meter between transceivers). Up to 100 computers can
be connected to the network. 3BNET provides bulk file
transfer, remote command execution, electronic mail, and an Application
Programming Interface to allow users to develop custom network software.

The 3BNET Network Interface for the AT&T 3B2/300 Computer is based in
the Intel 82586 Ethernet chip set with the Intel 80186 providing bus
handshake control. The card does all of the level 2 protocol processing
and allows 3BNET to be a low host overhead communications feature.
3BNET itself is AT&T's high level protocol above the Ethernet Data Link Layer.

The Application Programming Interface allows programmers to directly access
network services at the Ethernet Data Link Layer through the use of standard
UNIX System calls: read, write, open, close, ioctl. The programmer can
construct programs that communicate with each other by sending Ethernet
packets that they construct. The user opens an Application Port for reading
from the network or writing to the network or both, sets
several parameters (such as his symbolic address for receiving packets,
protocol type, etc.), and is then ready to send/receive packets.
I have written file servers, print servers, etc. to be used at COMDEX
shows to demonstrate the Application Programming Interface.

Got the idea? Or should I stay on my soap box a while longer?

                                           Chris Donahue
                                           AT&T Info. Sys.
                                           Application Engineering
                                           Lisle, IL

guy@sun.uucp (Guy Harris) (06/01/85)

> 3BNET provides bulk file transfer, remote command execution, electronic
> mail, and an Application Programming Interface to allow users to develop
> custom network software.
> 
> The Application Programming Interface allows programmers to directly access
> network services at the Ethernet Data Link Layer through the use of standard
> UNIX System calls: read, write, open, close, ioctl. The programmer can
> construct programs that communicate with each other by sending Ethernet
> packets that they construct. The user opens an Application Port for reading
> from the network or writing to the network or both, sets
> several parameters (such as his symbolic address for receiving packets,
> protocol type, etc.), and is then ready to send/receive packets.

Why not just provide TCP and IP (or XNS protocols, or ISO protocols, or
whatever) on top of Ethernet, and serial lines, and Hyperchannel, and the
PCL-11, and...?  There are already standard protocols in the Internet
(TCP/IP) protocol suite for bulk file transfer and electronic mail.  You can
stick UUCP on top of TCP and get another bulk file transfer and remote
command execution protocol (you can also use it for mail but it's not as
nice).  You can talk to any other machine which supports those protocols.
*AND* you can write one bulk file transfer server, one mail server, one
remote command execution server, etc. and use it with all those different
communications devices.

The software isn't too expensive; the University of California doesn't
charge too much for a tape, and there are plenty of companies out there
distributing it - I'm sure they wouldn't mind adding AT&T to the list...

	Guy Harris

cwd@cuae2.UUCP (Chris Donahue) (06/05/85)

> Why not just provide TCP and IP (or XNS protocols, or ISO protocols, or
> whatever) on top of Ethernet, and serial lines, and Hyperchannel, and the
> PCL-11, and...? 
> 	Guy Harris

ISO protocols are coming! Perhaps you need the proceedings of the Networking
Sessions from the last UNIFORUM (Jan., 1985).

Chris Donahue
AT&T Information Systems
Application Engineering

PS - It is always interesting to see where responses wind up.

karn@petrus.UUCP (06/06/85)

> > Why not just provide TCP and IP (or XNS protocols, or ISO protocols, or
> > whatever) on top of Ethernet, and serial lines, and Hyperchannel, and the
> > PCL-11, and...? 
> > 	Guy Harris
> 
> ISO protocols are coming! Perhaps you need the proceedings of the Networking
> Sessions from the last UNIFORUM (Jan., 1985).

Where have we heard *this* one before? For some excellent insight into
whether ISO is worth waiting for, particularly if you already have TCP/IP,
check out the chapter "The Illusion of Vendor Support" in Michael
Padlipsky's recent book "The Elements of Networking Style".  You might also
check out the recent ARPA RFCs and related discussions on a proposed DoD
conversion from TCP to ISO TP-4.

If you're unable to find these references, the bottom line is "don't hold
your breath". Despite massive hype, ISO is likely to remain just (a lot) of
paper for at least the next 5 years.  As far as I'm concerned, AT&T's
versions of Unix will remain useless to me as long as they refuse to support
TCP/IP.

Phil

guy@sun.uucp (Guy Harris) (06/07/85)

> > Why not just provide TCP and IP (or XNS protocols, or ISO protocols, or
> > whatever) on top of Ethernet, and serial lines, and Hyperchannel, and the
> > PCL-11, and...? 
> > 	Guy Harris
> 
> ISO protocols are coming! Perhaps you need the proceedings of the Networking
> Sessions from the last UNIFORUM (Jan., 1985).

I knew AT&T had plans to provide the ISO protocols someday (I already read
the proceedings); the question is "why didn't the idea of providing an
implementation of a standard protocol suite for *all* its network
interfaces, and layering things like mail, remote command execution, etc. on
top of that protocol suite, occur to AT&T when it first built its PCL-11
software, or its Hyperchannel software, or its Ethernet software?"  The
Ethergunk provided with the COMMKIT software or whatever it's called isn't
useful except for having one UNIX system talk to another UNIX system; with
TCP or XNS, you can actually talk to non-UNIX systems on the wire (and lots
more).

The fact that it took until S5 for AT&T to provide a screen editor, until
S5R2 for AT&T to provide flexnames, until S5R2V2 to provide demand paging,
and until S5R3 or S5R4 or whatever to provide a network architecture as
opposed to a set of hacks may explain why a lot of UNIX users may be willing
to consider S5 "standard" but not to consider it good enough for their work.
One reason why there are so many flavors of UNIX out there is that lots of
necessary capabilities are not provided with the UNIX that comes from AT&T,
so other vendors have to add them; unfortunately, if you have N people who
want to implement some feature you end up with N+1 implementations.
However, N+1 implementations is frequently better than 0 implementations.

	Guy Harris

sjl@amdahl.UUCP (Steve Langdon) (06/11/85)

...
> > ISO protocols are coming! Perhaps you need the proceedings of the Networking
> > Sessions from the last UNIFORUM (Jan., 1985).
> 
> Where have we heard *this* one before? For some excellent insight into
> whether ISO is worth waiting for, particularly if you already have TCP/IP,
> check out the chapter "The Illusion of Vendor Support" in Michael
> Padlipsky's recent book "The Elements of Networking Style".  You might also
> check out the recent ARPA RFCs and related discussions on a proposed DoD
> conversion from TCP to ISO TP-4.
> 
> If you're unable to find these references, the bottom line is "don't hold
> your breath". Despite massive hype, ISO is likely to remain just (a lot) of
> paper for at least the next 5 years.  As far as I'm concerned, AT&T's
> versions of Unix will remain useless to me as long as they refuse to support
> TCP/IP.
> 
> Phil

Your comments on the ISO OSI protocols would have been appropriate if
you had posted them in 1980, but are rather dated in 1985.  If you want
proof I would recommend that you have a look at the demo planned for
the AUTOFACT '85 show.  Over a dozen vendors including AT&T, DEC, Gould
Honeywell, HP, IBM, Motorola and NCR are due to participate in a multi-
vendor network based on OSI protocols.  Despite Mr. Padlipsky's superb
piece of polemic, the OSI protocols are going to be implemented and used.

I would be the last person to claim that the OSI protocols will displace
TCP/IP in a short period of time.  However, you should have noted that
the NRC report on transport protocols recommended that ISO Transport
class 4 (TP4) should replace TCP.  While the DOD is likely to take it's
own sweet time about implementing the change, you can be sure that NATO
pressure will lead to use of TP4.

By the way, I agree with your contention that TCP/IP support is something
that is useful in current systems.
-- 
Stephen J. Langdon                  ...!{ihnp4,hplabs,sun,nsc}!amdahl!sjl

[ The article above is not an official statement from any organization
  in the known universe. ]

dyer@spdcc.UUCP (Steve Dyer) (06/23/86)

Is there an ethernet interface available for the 3B1 computer?
Can you relink the kernel to include new line disciplines for
the serial ports, etc.?

Please reply by mail.
-- 
Steve Dyer
dyer@harvard.HARVARD.EDU
{linus,wanginst,bbncca,bbnccv,harvard,ima,ihnp4}!spdcc!dyer