Re: Wanted: TCP/IP source


vwhite@nswc-g.ARPA
Mon, 16 Nov 87 12:00:36 est


ARPA: garnold@sun.com

-----------------------------------------------------------------------
>From usrey@gold.bacs.indiana.edu Fri Sep 11 16:14:28 1987

At indiana Unuversity we have a broadband cable plant that joins most of the
buildings on a very large campus. We have an ethernet channel on that system
that attaches mosts mainframe and mini's along with most PC LANs. The mini's
are mostly vaxes with Ultrix or VMS and the PC LANS are mostly ethernet based
running Novell. The PCs on the lans can access the hosts via tcpip programs
OR attach to a Novell server but is isnt too smooth switching between the two
applications. If you would like more detail regarding our network then feel
free to contact me.

Terry R. Usrey
usrey@gold.bacs.indiana.edu
------

-----------------------------------------------------------------------
>From @wiscvm.wisc.edu:TS0400@OHSTVMA.BITNET Thu Sep 10 16:20:24 1987

We are solving this problem as follows. Banyan servers are connected to
PC Lans, via either ethernet or token ring (both are supported). The servers
provide a very friendly user interface, and transparent file and print
access. The internal Banyan mail is not smtp-compatible, but we have
contracted with them to provide an smtp gateway function in the server that
will act as a post office and hold all PC mail until needed. That will be
available to us for testing in about 2 months, and after we accept it, Banyan
will sell it to everyone.
 In the meantime, tcp/ip software from FTP, Inc can be put in the PCs which
supports smtp,ftp and telnet directly to the PC, with the server acting as
a passthru device. The server is connected to the existing tcp/ip ethernets
we have, on a separate port from the PC LAN. FTP, inc software will be RFC
compliant in the near future. Banyan will be integrating it into their
product more in the future so that FTP and Telnet will also be transparent
eventually and ftp, inc software will no longer be required on each PC.

                                           Bob Dixon
                                           Ohio State University

----------------------------------------------------------------------------
>From pcip-request@louie.udel.edu Thu Sep 17 16:37:54 1987 remote from nswc-g

  Banyan says that in a few months their server will provide tcp/ip functions
to PC users on the LAN as if the users were on a mainframe. The server has a
single IP address, and maps Banyan-style operations into tcp/ip operations
when dealing with the outside world. For example, users create mail with the
normal Banyan-specific menu syntax, etc but when required by its address, the
mail is forwarded by the server to the internet as smtp. Incoming mail
carries the internal Banyan address as the "user" portion and the server
adress as the "host" portion of the internet mail address. The server acts as
a post office and holds the mail until requested by a PC user.

                                            Bob Dixon
                                            Ohio State University

-------------------------------------------------------------------------
>From @WISCVM.WISC.EDU:TS0400@OHSTVMA.BITNET Fri Oct 2 16:02:36 1987

It is true that the Banyan server talks to the PCs using VINES protocol,
over either ethernet or token ring. However, as seriees of developments will
incorporate tcp/ip into that.
1. As of today ( I have it running in my own PC ) you can buy a version of
   FTP, Inc tcp/ip PC software which will coexist with VINES. That means
   that the server can be connected to an external tcp/ip network and the
   PC user can use the FTP, Inc software for telnet, ftp, etc just as if he
   were not in a Banyan network at all.
   It is not integrated into the Banyan menus, etc but it works fine.
2. You can buy (and we are, but don't have it yet) a program called LAN
   SHELL that enables the FTP stuff to be incorporated into the menus.
3. Banyan says they are incorporaring the FTP software into the server
   so that individual copies of FTP stuff would no longer be needed.
   Supposedly this year, but who knows for sure.

    A medium size Banyan supports about 25 users. They have 4 sizes for all
   needs. I have heard about the VAX plan and it sounds great, but nothing
   concrete yet. I can communicate fine with VAXes now with the tcp/ip
   software, but that does not give shared files, etc as the VINES thing would.

                                                Bob

----------------------------------------------------------------------------
>From @wiscvm.wisc.edu:BEAME@MCMASTER.BITNET Wed Sep 16 11:54:21 1987

Hello,
      NetBios IS the way to go for current PCs, but I have been talking to IBM
about the network interface in OS/2 and they responded that they still don't
know what communications are going to look like in the extended OS/2.

      NetBios over TCP/IP is the way to go. Bridge Communications (now part of
3Com corporation) has a PC board (PCS-1) which has TCP/IP, TELNET and RFC1001,
RFC1002 compliant NetBios. This solves everything but the mail problem. I
beleive the RFC for PC mail can be easily implimented and interfaced to the
TCP/IP available on the PCS-1 card as well as on a unix or Ultrix system.

      My firm is also working on an RFC compliant NetBios which uses the 3Com
EtherLink board. If you have time to wait, several companies are currently
working on compliant NetBioses. But as to an OS/2 version, only time (about
1 year) and IBM will tell.

    Carl Beame
    Development Analyst,
    McMaster University
    BEAME@MCMASTER.BITNET

----------------------------------------------------------------------------

I realize that this is long after the fact but maybe this will be
useful.

I manage end-user computing activities at DARPA and have (over the
past two years) been through an evaluation and procurement process to
put all DARPA personnel on a local net gatewayed to the Internet. The
system we chose is currently being installed.

We chose 3Com hardware and 3+ software although developments between
the time the RFP was drafted (approx. one year ago) and now would lead
me more towards something that I would expect to mature into a true
NETBIOS over TCP/IP product. Deciding when to freeze specifications
was the toughest part of the procurement, in retrospect it would have
been better to have been more general in our specification to take
advantage of developments that occurred during the procurement cycle.

As part of the procurement we specified an optional 3Com <-> Internet
gateway. This has been proposed but there is an associated
development cycle, it should be delivered around Feb. 1988. The
proposed solution looks like it might work (Wollongong on a Microvax)
but I am withholding judgement until I see it.

We chose 3Com primarily because of Mac support in addition to PC
support and ethernet, we would have rather had something based on the
DoD protocol suite, of course, but could not find any commercial
offerings. Our user base is approximately 120 PC's and 50 Macs, the
Macs population is growing faster than the PC population although we
passed one workstation per user (some have both and we also have users
who have machines at home) some time ago. We had an existing IEEE
802.3 cable plant and that influenced our decision heavily (it is
already gatewayed to the Milnet and Arpanet). Also, money was not so
much an issue as capabilities and speed.

I would be happy to give you more details on the things we have found
if you would like, I am not certain that a system the size of ours can
be scaled to one twenty times its size but it seems like your
objectives are similar to ours. Let me know if I can provide
additional information.

Glen Foster

----------------------------------------------------------------------------
>From >From vwhite@nswc-g Thu Oct 1 10:11:14 1987

Glen,

Thank you very much for your information. I think your situation
is very similar to ours, despite the difference in scale, and you
may be able to give us some useful advice.

You said you wish you had something that would evolve into a
NetBIOS over TCP implementation. Why do you want this instead
of one of the nonNetBIOS products now available, like pcnfs or
PC-Interface from Locus? Do your applications really need the
NetBIOS interface? What are the advantages of NetBIOS? Do
you think it is the up and coming standard and will win out
over competitors like nfs or pc-interface? We just aren't very
clear on these questions and would like to have the opinions
of somebody else who's been there. I realize that pcnfs, at least,
was not available when you made your purchase, but if you were
doing it today, what would you do?

Are your PCs clustered closely together or spread out over
a wider geographical area? How many do you put on one 3com
server?

Do you just use the 3com mail program? Will your gateway transfer
that to internet mail? We already have a lot of minicomputers
using smtp and must have a way to get the PCs to talk mail to
them from the outset.

Thanks for the help; I think we can learn a lot from you. If
it would be easier to talk about it over the phone you can
give me a call or send me your number.

Vicky White
(703) 663-7745
vwhite@nswc-g.arpa

----------------------------------------------------------------------------
>From gfoster@vax.darpa.mil Thu Oct 1 19:06:03 1987

Vicky,

I hope I can remember your questions, my main mail box is on a.isi.edu
but they are flakey and went down in the middle of my reply (twice!)

I think NETBIOS will be big (if OS/2 is big), I have seen a couple of
nice applications running on PC databases over NB (dBASE and Paradox).
When NB servers become multi-tasking in a standard way (OS/2) I think
we will see more developers writing applications that are truly
distributed. 3Com has stated that they are moving in that direction,
I met with them this morning and learned a good bit -- the bad news is
that they are not going to do much with TCP/IP on PC's.

I have PC-NFS on my desktop PC (actually an AST Premium 286) and have
been using it more lately than 3+. I am becoming more and more UNIX
oriented though and can not be considered an average user. It has
some bugs that may make it difficult for non-technical users.

We are all in one building, spread out between floors and have a thick
cable ethernet running in the phone closets from the first floor to
the twelfth (where the computer room is). (We actually have two
running parallel but that is another story.) To hook up the PC's, we
are using thin cable segments repeatered to the trunk, like:

                PC PC
                | |
  ----T-------------------
      |
      R
      |
======T======================T==================================
                             |
                             |
                             R
             PC |
             | |
        ---------------------T--------

T = transceiver, R = repeaters, PC = you guessed it

We hope to get away with no more than two thin segments per floor but
are pushing it on the length spec. The servers will be cabled to the
trunk with their own transceivers and xcvr cables so that if a user
trashes his cable he doesn't take down the whole net. We have found
some repeaters that will automagically isolate either side of the
cable if it is shorted or open. (American Photonics) We have had some
embarrassing outages using Xerox repeaters when the thin cable was
accidentally opened. These were reasonably easy to diagnose and
repair but we only had three segments, it would be a real pain if we
had a lot of places to look. Ethernet attachment hardware is a joke,
both thin cable and transceiver cable attachments are major headaches
and can easily be detached by a vacuum cleaner or curious user. (I
know how to handle this, it's just like my VCR!)

We are figuring 10-12 users per 3Server (u/3S), we want very high
performance and aren't as concerned about the cost. If we were
worried about the cost I would go to 20-25 u/3S in our environment
(mostly office automation -- word processing, spreadsheets and
communications) and I think we could handle up to 40 u/3S if we had to
and still have reasonable hard disk response. By reasonable I mean
about as fast as an XT hard disk or maybe a little faster. If I were
putting hefty dbms applications on, I would start at 4-6 u/3S and add
them one at a time until we got a problem. I would definitely get the
cache card with more than 15 u/3S (and probably will anyway). I would
never, ever try to use a concurrent workstation/server, Ctrl-Alt-Del
is too ingrained in PC users' minds.

The mail gateway is supposed to take mail intended to go off-site and
format it to RFC821/RFC822 etc. specs and then dump it back on the
ethernet where it will be picked up by the gateway. Locally we will
use 3+ mail and 3+Mac mail with hoped-for user transparency. Sure
hope it works . . .

I forget your other questions, give me a call if you want (703)



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:56 GMT