Re: Wanted: TCP/IP source


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


BAD MSG:
see how we have things laid out. The installation should progress now
hrough Nov. 20th. We took a trip over to the Census Bureau early on
in our evaluation and it was very enlightening. NSF is also scoping
out PC nets and you might be able to get some pointers from them.

Good luck,
Glen

----------------------------------------------------------------------------
notes from phone coversation with Glen Foster 10/5/87:

Reiterated that 3com was chosen primarily for Mac connection;
also, they seemed most agreeable to customizing to Darpa's
environment. He says Novell gave lip service this but wouldn't
really get down to brass tacks; his opinion is "Novell is market
driven company, 3Com is technology driven" (have we heard that
somewhere before?)

Says NFS and similar products which have come down to PCs from
minis don't take advantage of all the features of a pc; tend to
treat them like dumb terminals; ignore alt key, function keys;
also require more knowledge and sophistication from user; products
which originate from PC side are more PC user friendly, but
don't always provide services desired (like ftp or smtp)

Their vendor (Management Systems Designers of Vienna) is going
to provide an smtp gateway for them (in 90 days); they'll use
3Com mail on the lan

He suggested we talk to Census Bureau and NSF for further ideas.
I attempted to contact both but have been unsuccessful so far.

-vew

-----------------------------------------------------------------------
>From as-pln-bf@HUACHUCA-EM.ARPA Fri Oct 9 18:51:51 1987

You might be able to get the info you are looking for from the engineers
that are at the Army Small Computer Engineering Center (SCEC). They are
very sharp on networks etc. Their DDN address is USASCEC 'at' SIMTEL20.ARPA.

-----------------------------------------------------------------------
>From USASCEC@SIMTEL20.ARPA Wed Oct 28 12:42:56 1987

  Sorry for the late response - most of our folks have been TDY. I'm afraid
that we're not going to be able to provide much help to you, since we preach
the use of OSI standards - right now we're using TP4 instead of TCP/IP, and
we are not going back. If you want to know how to do what you intend to
with TP4, we can tell you more. Basically, we support MS-NET protocols on
802.3 LANs, using PC hardware from either Ungermann-Bass or Intel. We have
XENIX (Intel 310/320) and UNIX(Sperry 5000/80) based servers, implementing
the Intel developed OpenNET protocols(compatible w/ MS-NET). Our servers
have the capability to connect to the DDN (X.25) and SNA world. The most
important detail is that all the above equipment is available from
standard Army contracts. Also, the next major office automation procurement
will be for systems that connect to that same LAN. The Navy and DLA are
going in with us on that one, so although it will be an Army contract,
it looks as if ALL DoD agencies might be able to order from it. In case
you don't know about it, the AF tends to support TCP/IP protocols. You
might check with them if you're stuck with that.
  -- CPT David Anselmi
     AV 879-8247/7450
--------------------------------------------------------------------------

notes from phone conversation with David Anselmi
9 Nov 87

They have Intel's OpenNet, which is Netb on iso; PCs can be file and
print servers, though for performance not recommended; for servers
they are using the Intel 310 (a 286 system) and 320 (a 386); says with
their workload, he recommends no more than 8 users to a 386 server, though
it's supposed to support 12.

has virtual drive; virtual terminal service; file upload/download; can
use menu interface for all interaction, including system administration;
performance good except he doesn't like the menu
interface and prefers to use direct commands

for mail they log into the server over ethernet or rs232; mail available
only to and from the servers; technically feasible to do it to PCs,
but they didn't; no SMTP; OpenNet mail;

have run network DBASE III over this and it's okay;

hasn't tried other NetBIOS networks here (like IBM PC Net or Network OS)
but thinks they ought to work

no mac support

They are hoping to buy minicomputers: Sperry
5000/880, to support up to 64 users; no advance info on actual performance;
(note: requiring POSIX conformance there); will run Unix V.2 with OpenNet;
not yet available. Minis should service PCs just like their Intels. award
expected sometime 88 (June-Aug-Sept); other DoD may be able to buy off it.

now have a Sperry 5000 which is their DDN gateway for ftp and telnet;
working on mail interface; also have a tcp, ddn gateway on an Intel
320; this Intel can also support a tcp lan in addition to the iso
lan;

not going to specify x.400 yet; will do it later

tcp to iso companies: 1)Retix, Santa Monica
                      2)Sydney, Vancouver

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

>From mcc@etn-wlv.eaton.com Fri Sep 11 10:14:41 1987

Vicky, Dan, et. al.:

If you can get access to the Request For Proposal (RFP) and the vendor propos-
als for LONS, RAPIDE, UTAIN/MAIS, and ULANA; you may find some of the answers
to the questions that you have raised.

LONS and its predecessor LONEX (Local Office Network Experiment) are probably
more in line with what you want to do. LONEX has been operational since the
early 80's at Rome Air Development Center (RADC), Griffiss AFB and has links
to and facilities at Hanscom Field and Wright-Patterson AFB. This message is
being generated from home on a Tandy 2000 linked to the LONEX development and
maintenance network at EATON IMSD in Westlake Village, CA which is also linked
into RADC-LONEX.ARPA.

LONEX was originally designed for a broadband with dedicated links to Hanscom
and Wright-Patterson; however, the broadband has been replaced with Ethernet
and the dedicated links are being replaced by the MILNET. The original plan
was to support a large number of users using VT100 or VT100 compatible term-
inals; however, that is also changing with many of the organisations using
LONEX replacing them with PC's.

PC's are not as fully integrated as you would like and generally use terminal
emulation packages to interface with the network. I, personally, use the
Softronic's SoftermPC package on which I have implemented a seamless disk
capability so that disks on the network look like local hard disks to my PC.
I can tell you from experience it can be painful--applications developed for
MS-DOS choke if you have to use UNIX pathnames to get to your data. For
some silly reason they attempt to parse switches whenever they see a "/".

Anyway, the LONEX system runs on anything that can run on any processor that
supports 2.9bsd or 4.3bsd. It goes "boom" on System Vanilla. It supports
several of the more popular spreadsheet programs and databases and depending
on the size of your spreadsheets moves the processing to more appropriate
machines. Users in essence always execute from their home processor regard-
less of where they may be and for the most part its transparent to the user.
If you normally work at Hanscom but are temporarily at Wright Patterson, you
may notice some latency. (This feature is probably the biggest reason why
there hasn't been a stronger hue and cry for more fully integrating PCs into
the system. As long as you can get to a TAC, you can work on your reports
from anywhere in the world. You don't have to lug the PC along and if you're
forced to fly commercial, you avoid the hassle at customs where they try to
extract the import duties on your PC).

Enough this. Request a tour and briefing from RADC to determine if it is
useful and to find the pitfalls.

Merton Campbell Crockett mcc@etn-wlv.eaton.com
AN/GYQ-21(V) Program mcc%lonex@etn-wlv.eaton.com
EATON Information Management Systems
31717 La Tienda Drive, Box 5009
Westlake Village, CA 91539

----------------------------------------------------------------------------
>From perry@vax.darpa.mil Fri Sep 11 15:46:42 1987

My understanding from the folks at RADC is the LONEX is going away, an
no further enhancements are allowed to the system. I wonder what
they are moving to?

dennis
----------------------------------------------------------------------------

>From sms@radc-lonex.arpa Sat Sep 12 17:22:05 1987
>My understanding from the folks at RADC is the LONEX is going away, an
>no further enhancements are allowed to the system. I wonder what
>they are moving to?
>
>dennis
>-------
>
        As a 'founding father' of the LONEX system here are my two (and a
        half) cents worth...

        The rumours do persist of LONEX's departure, primarily coming from
        those who are responsible for the successor system. The system
        that was supposed to have replaced LONEX is almost a year and a
        half behind schedule and does not even come close to providing
        the services and capabilities of the present system. This isn't
        the place i suspect to delve into the shortcomings/etc of the
        respective systems, if anyone wants my perspective drop me a line
        (obviously it leans towards the current system).

        The LONEX contract runs thru March 1988 at least, so we'll be here
        for a while yet. Enhancements are being quietly done, major changes
        are not allowed on a production system.

        Besides, as Jerry Pournelle says (loosely remembered)
        "Last year's state of the art is today's production system".

                                Steven M. Schultz
                                sms@radc-lonex.arpa
                                (usually sms@etn-wlv.eaton.com)
        todays

----------------------------------------------------------------------------
>From mcc@etn-wlv.eaton.com Sat Sep 12 17:46:20 1987

Dennis:

The operational system to replace the experimental system is LONS and that
is the official line; however, I think there is a great deal of resistance
at the LONEX user level. I'm not sure what the final configuration of LONS
is going to be; however, one component seems to be a single VAX system that
provides the same user services provided by the array of PDP11/44, PDP11/70,
and VAX systems used ithe LONEX system.

While LONS is the "official" system, I doubt that LONEX will disappear in
the near future. You have a large group of users that are familiar with the
facilities of LONEX. Experience at EATON indicates that it is very easy to
move secretaries whose primary use of the system to prepare letters and mem-
orandae from one system to another but it is quite another to move people
that use a system for preparing technical documentation and proposals part-
icularly if these documents are going to be modified and reproduced over a
period of time. In essence, the "old" system will not be replaced until a
catastrophic event occurs--because no one wants to spend the money to con-
vert all the data from the formats required by the "old" system to that re-
quited by the "new" system.

Merton Campbell Crockett

----------------------------------------------------------------------------
>From perry@vax.darpa.mil Sat Sep 12 18:06:16 1987

Merton, I had heard the LONEX was going to go away because I had
asked the RADC people to fix lonex so that, at least on there system,
mail send to an individual would include who is on the 'cc' line. I
wanted to make certain that eveyone involved in the discussion was
being copied. Lonex apparently cannot do that. It sends out mail
with blank cc lines and I do not know who else got the message, nor
can I answer to everyone. If lonex is going to be around, this would
be a good thing to fix. The RADC peole say that this would be a major
change to the guts of the system and will not be done.

dennis

----------------------------------------------------------------------------
>From mcc@etn-wlv.eaton.com Sat Sep 12 18:58:53 1987

Dennis:

I'm a little confused. The LONEX Mail Facility does indicate who the cc:
recipients are on each message when you display the message. Of course,
there may be some slight differences between the RADC and EATON versions.
A definitive answer can be gotten from Steven M Schultz (sms@etn-wlv.eaton.com)
currently on location (sms@radc-lonex.arpa) about any differences.

Merton Campbell Crockett

----------------------------------------------------------------------------
>From perry@vax.darpa.mil Sat Sep 12 19:14:14 1987

Merton, we made a test, and at least the RADC lonex does not include
any names on the cc line. It does indeed send copies of the mail
to those indicated on the cc lines of the lonex user who generates
the mail, but the mail that is sent out does not include that
information. Instead, lonex generates a mail message to everyone
as if they were the only one getting the message.

dennis

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

>From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987
>
>Dennis:
>
>I did a few tests in response to your last message. The behaviour of the
>LONEX Mail Facility is very dependent upon where the mail originates. When
>the mail is originated from the LONEX Mail Facility, all recipients of the
>message will be displayed with the exception of the bcc: recipients. When
>the mail is received from the in-house ELIS system, the bcc: recipients are
>displayed as well--for some reason that system includes the bcc: in all
>message headers.
>
>When the message originates on the DDN, only the addressee, originator, and
>the individual forwarding the mail appears. If there are multiple address-
>ees in the To: line or any recipients in the Cc: line, the information is
>lost. The problem is at the transition between the two mail systems. The
>problem is the mapping between the two header formats; however, I shouldn't
>think it is that substantial a problem to fix. Steve Schultz probably can
>give the best estimate of the changes required.
>
>Merton

--------------------------------------------------------------------------
Merton, Dennis, Dan, Vicky,

        Guess it's about time i got in the act what with my name being
        mentioned (i felt my ears burning, so i figured someone was
        talking about me).

        RE: the '>'d stuff below:

        The 'problem' with the LONEX mail system not generating Cc: lines
        quite right was only brought to my attention a few weeks ago and
        since then there has been precious little time to look into it
        in detail. Now that i know 1) that there is a problem and 2)
        that somebody cares(?) i will attend to it. Don't hold your breath
        (people turn blue that way) but eventually i'll get it patched up.

                                Steven M. Schultz
                                (sms@etn-wlv.eaton.com normally
                                 right now i'm TDY at "sms@radc-lonex.arpa")
P.S. Even with its problems, the LONEX mail system can send/receive mail
     from the DDN, something that LONS can not at the present do.
-----------------------------------------------------------------------
>From mcc@etn-wlv.eaton.com Sat Sep 12 22:10:03 1987
>
>Dennis:
>
>
>When the message originates on the DDN, only the addressee, originator, and
>the individual forwarding the mail appears. If there are multiple address-
>ees in the To: line or any recipients in the Cc: line, the information is
>lost. The problem is at the transition between the two mail systems. The
>problem is the mapping between the two header formats; however, I shouldn't
>think it is that substantial a problem to fix. Steve Schultz probably can
>give the best estimate of the changes required.
>
>Merton

--------------------------------------------------------------------------
29 September 1987

Merton, Dennis, Steven:

Thank you for responses about the LONEX system. We have some
questions:

It sounds as if the primary function of LONEX is
keeping most of the processing on a larger system,
away from the PCs, but is doing load balancing to share
the work among several such larger systems. Are we on the
right track? How about the supported spreadsheet and database
programs; are they implemented on the server or the PCs?

Where is the mail delivered? Do users have mailboxes on the
server? (It doesn't sound like mail is delivered directly
to the PC.) Can users send mail from the PC or must they
do so directly from the server? How about printing? Must
the user queue print jobs from the server or can he do so from
the PC?

Why are these terminals and PCs connected to your larger systems
via an ethernet? Most of the implementations we've seen in
which PCs accessed servers only as terminal emulators use asynchronous
connections; it's cheaper and can handle the requirement. Is
LONEX offering a service that makes the ethernet important? (perhaps
those database programs are distributed database servers?)

You said LONEX runs on 2.9bsd or 4.3. Did you mean, in addition,
anything in the middle? How about vendor implementations of 4.2 such
as those of Pyramid or CCI? What software is required on the PC?

Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA)
implement a file server? If you could describe them briefly we might
know whether it was worthwhile to go looking for more information.

Thanks for the help! We want to learn as much as we can
from other people before we make any decisions.

Vicky White
Code K33
NSWC
Dahlgren, VA 22448
(703) 663-7745
vwhite@nswc-g.arpa

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

>From sms@etn-wlv.eaton.com Tue Sep 29 19:48:32 1987

Vicky, Dennis,

        Good to hear from you again. I'm back from the East coast
        (not by choice, i think upstate NY is nicer than So. Cal.).

        I've bracketed my responses in lines of ===== below.

                                steven m. schultz
                                sms@etn-wlv.eaton.com
------------------------------------------------------------------------
>
>It sounds as if the primary function of LONEX is
>keeping most of the processing on a larger system,
>away from the PCs, but is doing load balancing to share
>the work among several such larger systems. Are we on the
>right track? How about the supported spreadsheet and database
>programs; are they implemented on the server or the PCs?
======
        Correct, mostly. The 'system' at Griffiss AFB and Hanscom (Bedford MA)
        consists of 16 'mini'computers - 14 PDP-11/44s running 2.9BSD
        and two VAX-11/750s running 4.3BSD (the system in Westlake Village CA
        has two PDP-11/44s and 1 VAX-11/750). The QCALC spreadsheet program
        is a corehog, users on the PDP-11s run QCALC thru a servor over the
        ethernet. The database we have (although not too many users choose
        to learn it) is UNIFY and that runs directly on each processor (PDP-11s
        included).
======

>
>Where is the mail delivered? Do users have mailboxes on the
>server? (It doesn't sound like mail is delivered directly
>to the PC.) Can users send mail from the PC or must they
>do so directly from the server? How about printing? Must
>the user queue print jobs from the server or can he do so from
>the PC?
======
        The mail is delivered to a users home processor (queued if need
        be until it comes up), i.e one of the PDP-11s or the VAX (at
        present only special users are allowed on the VAX). DDN mail
        (and yes, i've a fix to our incorrect mail headers due to be
        released Real Soon Now). I am a little confused at your mention
        of 'servor', perhaps it's a semantic nit, but i view them more as
        'hosts' or 'home processors' since that's where the files, etc
        reside.
        Printing can be done from any processor to any printer in the
        network via the spooling system that runs on the hosts.
======
>
>Why are these terminals and PCs connected to your larger systems
>via an ethernet? Most of the implementations we've seen in
>which PCs accessed servers only as terminal emulators use asynchronous
>connections; it's cheaper and can handle the requirement. Is
>LONEX offering a service that makes the ethernet important? (perhaps
>those database programs are distributed database servers?)
======
        Umm, sounds like something got mangled in transmission... You're
        quite right in that the terminals and any PCs present are connected
        via serial lines (DH11 or DMF32) and the PCs run terminal emulators.
        The ethernet is used for the hosts to communicate on, not for terminals.
======
>
>You said LONEX runs on 2.9bsd or 4.3. Did you mean, in addition,
>anything in the middle? How about vendor implementations of 4.2 such
>as those of Pyramid or CCI? What software is required on the PC?
======
        A qualified 'almost yes' to this one. If/when I can convert
        completely to TCP/IP as the communications package (perhaps possible
        with 2.10BSD) instead of the homerolled XNS variant presently in
        use THEN LONEX should run on any BSD (i've a low tolerance level
        for System Vanilla) originated Unix.

        The present system has much larger numbers of 16bit machines than
        32bit machines, so the PDP-11s have been where the software was
        primarily written and tested before porting to the VAXen.

        All of the 'applications'/'user programs' in the LONEX system DO
        run with just recompilation on 4.3 or 2.9 as the sources are identical.
        I'm sure there are machine dependencies left even after running 'lint',
        but they should be fairly easy to squash.

        At present the placement of some of the local directories and files
        is hysterical (oops, historical) and should be changed, this would
        make for easier merging with other versions of Unix.

        The most commonly used software for the PC is a good VT1XX emulator
        with Kermit or Xmodem.
=====
>
>Do any of the other packages you mentioned (RAPIDE, UTAIN/MAIS, or ULANA)
>implement a file server? If you could describe them briefly we might
>know whether it was worthwhile to go looking for more information.
>
>Thanks for the help! We want to learn as much as we can
>from other people before we make any decisions.
=====
        When Merton gets back from Germany he can try to answer this one,
        i'm not very knoweledgeable about the other programs you mentioned,
        keeping a network here and two back east hanging together plus
        whatever tweeks the software needs seems to be enough activity for
        me.

        It appears to me that you are looking for a system that is oriented
        around PCs rather than CRTs, or have i missed something? I think
        Merton mentioned in one of his items that PCs at present are not
        tightly integrated into LONEX (not too suprising, LONEX effectively
        predates PCs and the government did buy/lease an awful lot of VT1XX
        and VT2XX terminals), beyond file transfer capabilities.

        Hope this answers more questions than it raises, feel free to
        ask for clarification on any mud i wrote.

        Later...

                                steven m. schultz
                                EATON IMSD
                                31717 La Tienda Dr.
                                MS 228
                                Westlake Village CA 91359

                                sms@etn-wlv.eaton.com
=====

--------------------------------------------------------------------------
>From timk@ncsa.ncsa.uiuc.edu Fri Sep 11 11:13:42 1987

Vicky,

At the National Center for Supercomputing Applications, we are facing the
same types of connection problems that you mentioned in the note which
was forwarded to the ARPANET tcp-ip mailing list. We have looked at most
of the alternatives you have, and have gone through several steps which
you may want to learn from. We have Suns, Vaxes, Alliant, Silicon Graphics,
and a Cray XMP. We access them from PCs and Macs with TCP/IP.

1. Transparent file systems to Suns and other minis are not as valuable to
   PC users as you might think. We use local hard disks and convenient
   ftp service. LANS, like Novell, which provide file services without
   involving the minis, would be more attractive, though we don't use any.
   (substitute "large workstation" for minicomputer if you like)

2. The most important thing for us has been powerful terminal access to the
   larger computers. We developed our own because the available ones were
   not powerful enough. File transfer is next most important.

3. Try our TCP/IP package for PCs and Macs. I am appending our old release
   information, the new version will support new Ethernet boards, have
   Tektronix graphics emulation and several more new features (October 1).

4. We have "rigged" solutions which I am willing to discuss, which cover the
   mail and printing parts of your requirement list. We are planning to work
   on "proper" solutions to these problems in the next year.

5. Most of the people I talk to lean toward PC-NFS when choosing the commercial
   versions. My personal opinion is that they are solving the wrong problem.

Good luck in your search, give me a call if it will help (217)244-0638.

Tim Krauskopf
National Center for Supercomputing Applications (NCSA)
University of Illinois

timk%newton@uxc.cso.uiuc.edu (ARPA)
14013@ncsavmsa (BITNET)

Fact Sheet
----------

National Center for Supercomputing Applications presents:

NCSA Telnet for the PC, version 1.1
NCSA Telnet for the Macintosh, version 1.1

These programs are copyrighted, but distributed in binary form with
no license fee. Source code is not available. We are exploring the
possibility of distributing linkable libraries which support TCP/IP.

Description:
-----------
NCSA Telnet for the PC is an MS/DOS application which enhances
communication with other computers over Ethernet. It uses the DARPA
standard TCP/IP protocols, giving the PC access to all of the
machines on the ARPANET and NSFnet. The basic framework consists of
the standard telnet with an FTP server built-in. During a telnet
session, you can initiate an FTP session from a remote host and
transfer files to and from your PC, in the background. NCSA Telnet
provides a virtual terminal, emulating a VT100, which can connect to
any telnet host on the network. A unique multiple session capability
makes this multiple virtual terminals by allowing you to log in to
several machines at once, or one machine several times, with each
session completely separate from the others. A simple keystroke
switches the screen display from one session to the next.

NCSA Telnet for the Macintosh takes these basic features and adds
support for the user interface that Macintosh users expect from Mac
applications. Each session is displayed in a different window,
Macintosh menus are used throughout, desk accessories are supported,
and text can be copied from a session window to the clipboard. With
a large screen, such as the Macintosh II's displays or the Radius
display, several simulataneous VT100 screens can be viewed at the
same time without overlapping windows.

Development of NCSA Telnet began in August of 1986 in an effort to
improve microcomputer access to NCSA's Cray XMP supercomputer and the
various other workstations connected to our local networks. Our
local Ethernet supports VAXes, Sun workstations, and an Alliant FX/8,
which can all be reached from a PC, using NCSA Telnet. Shortly after
the original implementation on the PC, we decided to port the code to
the Macintosh for use over Appletalk, through a Kinetics Appletalk to
Ethernet gateway. These programs have been in constant use at NCSA
since January, 1987 and are still undergoing improvements.

Features included in version 1.1 of NCSA Telnet:
-----------------------------------------------
DARPA standard telnet
Built-in standard FTP server for file transfer
VT102 emulation in multiple, simultaneous sessions
Class A,B and C addressing with standard subnetting
Each session in a different window (Macintosh)
Tektronix 4010 graphics emulation (Macintosh)
Supports Croft gateway, i.e. KIP (Macintosh)
Capture text to a file (PC)
Full color support (PC)

How to obtain:
-------------
1) Anonymous FTP from uxc.cso.uiuc.edu in the NCSA subdirectory.

The PC version is a tar file which contain binary files. After the
files are extracted from the tar file, some binary transfer (e.g.
kermit) should be used to download the files to the PC. The
Macintosh version is several files encoded with BinHex 4.0. Download
them with a similar transfer method (kermit) and use BinHex 4.0 to
extract the files. Printable documentation is included with each
version; the Mac documentation is in MacWrite format. After
downloading, you may copy the files as often as you wish, unmodified,
in binary form, with the copyright notices intact.

2) With appropriate communications software, the program and documentation
can be downloaded over phone lines from the University of Illinois EXCEL
bulletin board. The phone number is (217)333-8301 and it operates at
300,1200 and 2400 baud. For the Macintosh version your communications
software must support the MacBinary protocol. Kermit or Xmodem can be
used to download the PC version. (available 7/8/87)

3) On-disk copies, with a printed manual are available for $20 each, which
covers handling and postage. Orders can only be accepted if accompanied
by a check made out to the University of Illinois. Send to:

NCSA Telnet orders (specify PC or Macintosh version)
152 Computing Applications Building
605 E. Springfield Ave.
Champaign, IL 61820

Hardware required:
-----------------
PC: IBM PC, AT or compatible. 3COM 3C501 Etherlink board.
        Support for other boards planned, which would you require?
        Upcoming: Ungermann-Bass, IBM, MICOM NI5210

Mac: Macintosh Plus, SE or Macintosh II.
        Kinetics, Inc. FastPath, EtherSC or the new SE Ethernet board.
        Kinetics gateway software or Stanford KIP (Croft) gateway software.

The best source of information about Kinetics is directly from the company.
Kinetics Inc. FastPath approx. $2500
Suite 110 EtherSC approx. $1250
2500 Camino Diablo educational and volume discounts
Walnut Creek, CA 94596
(415) 947-0998

Other questions:
---------------
mail to telbug%newton@uxc.cso.uiuc.edu

=============================================================
notes from phone conversation with Tim Sept. 11 87:

Tim's reasons for not wanting a pc-nfs like solution are:

        1)their users don't want it; they have a heavy need
        to use the Cray directly and do the work there; converting
        these files from Unix to DOS or the other way around is
        just too much trouble.

        2)It is not, in his opinion, good computer science.
        He says, if you really want an nfs-like environment, get
        something from a PC lan manufacturer like Novell. They can
        do it better because that's all they do; they aren't trying
        to do a bunch of other things in their operating system
        like Unix is. Therefore the design is cleaner and has
        fewer problems. If you just want file transfers without
        necessarily the tranparency of nfs, a telnet-like program is
        better. (same reasons: less overhead, less to do, cleaner
        design) He likes separating the worlds of big machines
        and pcs, and thinks you get
        better vendor support and happier users that way.

By the way, I guess many of you knew this, but he says smtp
has a retrieval facility (like the POP mail facility) but it isn't well
known and isn't implemented in Berkeley.

They have tried 3com and Unix on Suns. They wrote their own telnet
application with a built in ftp which he actively promotes; try it/you'll
like it. Why did they do that instead of using an existing implementation?
Try it and we'll see how much better theirs is.

They are moving toward POP. They want to avoid a simple smtp on a PC
since it requires leaving the PC on overnight.



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