NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/amiga/datacomm/7800

Internet Message Format | 1992-11-20 | 7.8 KB

Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!uwm.edu!rutgers!cbmvax!dlarson
From: [e-mail] (Dale Larson)
Newsgroups: comp.sys.amiga.datacomm
Subject: Re: amiga netwrk stdrd api
Message-ID: <[e-mail]>
Date: 20 Nov 92 16:47:44 GMT
References: <[e-mail]>
Reply-To: [e-mail] (Dale Larson)
Organization: Commodore Engineering
Lines: 170


Newsgroups: comp.sys.amiga.datacomm
Subject: Re: amiga netwrk stdrd api (LONG)
Summary:
Expires:
References: <[e-mail]>
Sender:
Reply-To: [e-mail] (Dale Larson)
Followup-To:
Distribution:
Organization: Commodore Engineering
Keywords:

In article <[e-mail]> [e-mail] writes:
>Like it or not, all existing network APIs are designed to work well with the
>OS they were born in. Porting them over to another system often results in
>poor integration with the new environment, incompatibilities with the original
>implementation and resorting to gory hacks to get things working.

How true!

>So, why not go for an All-Amiga networking API?

Good idea.

>Please note that changing the API has nothing to do with the protocol you
>are using. You should be able to use TCP/IP, or any other transport, from
>a standard (well designed) Amiga network API.

This isn't entirely true.  In theory, yes, and it is a noble goal, but in
practice, it just doesn't work that way, at least not with current technology.
Hopefully, the state of the art will soon advance to make this more reasonable,
but I'm not holding my breath.

When it comes to implementation and application, there are several problems.

One is that even if every Amiga program which is network aware can use any
given protocol stack, there aren't equivalent programs on all other (non-Amiga)
side.  For example, if you want to remotely log into another machine, you use
a program like rlogin or telnet.  Those applications are generally implemented
on machines with a TCP/IP transport.  There are other application protocols for
other transports.  If you have to implement (or port) a dozen remote login
programs anyway, you might as well do them for a particular protocol stack in
that stack's "native" API.

Second, each transport has it's own quirks, provides slightly different
services, etc.  Applications protocols must be designed with these in mind.
Thus, to generalize an application protocol to several transports necessitates
accounting for each individual protocol anyway.  It increases application size
and complexity.  You might just as well write a few different versions of the
app.

Fortunately, this isn't a big deal.  If one API standard is created (and
implemented with some standard protocol stack) as the standard for Amiga-only
applications, Amiga network-aware apps should be much easier to write and more
abundant.  You can also run multiple protocol stacks on the Amiga easy as pie.
If you need connectivity to machines using different transports (and thus
different applications), you can have it by running multiple protocols.


>Also note that it wouldn't be TOO hard to recode a socket (or other API)
>application for a standard Amiga API. In fact the Amiga API would more or
>less provide the same sort of services (connect/disconnect/accept/send/receive)
>only through a *cleaner* interface.

NOT.  With very simple applications, maybe.  More complex applications (even
things like the standard Berkeley networking utilities) are much more difficult.
Try doing this with an application with truly complex networking needs (i.e.,
real-time, atomic transaction processing, reliable multicast, etc.), and you
will find really big problems.

BTW, your example API appears to assume a stream-oriented service
(connect/disconnect).  That alone precludes you from implementing a number of
application protocols.

>Now let me picture how a sample Amiga network application should work. This
>is NOT an API design (yet), but should clarify what I have in mind. No
>flames, please. Comments are welcome.

Not trying to flame -- we're dealing with very yucky stuff.  For a long time,
I wanted to do something like what you are after.  It is intellectually *very*
appealing.  It took a long time for reality to sink in.


>The main points I want to get through are :
>  1) I want to access multiple protocol stacks through the same API

What are you going to do if you can?  Again, you have to have an application
on the other side.

>  2) I want the API to be *designed for the Amiga OS*, specifically
>     supporting synchronous and asynchronous I/O, signals & c....

This is a reasonable expectation.

>- Should the  network.library actually be complemented by a network.device
>  so that we can do I/O via Exec calls : SendIO/DoIO, etc.... ?
>  (this is the sort of approach used by VMS/DECNET at the nontransparent
>   level. I may be wrong but maybe DNET does something like this...)

You probably want something like device IO, but not exactly.

>- Should the network.library actually have a network.handler, so that
>  we can do straight AmigaDOS I/O (both packet and file-oriented) ?
>  This option somewhat overlays the case of 'transparent' network
>  communication, discussed below.

There should be a network filesystem which is transparent to user and
applications programmers.  This has nothing to do with writing network-aware
apps.

>- Make it just a no-fuss library which resembles either but is none of
>  them (as I sort-of did in the example)?

I guess that's what I said when I said "something like, but not exactly."

>Another big issue is the need to have standard AmigaDOS applications
>operate over a network transparently, without calling a networking API.

It's called a network filesystem.

>It seems that the current approach taken by most Amiga networking software
>works like "mount the remote file/device, then use it as if it were a
>local filesystem". This scheme, notably used by NFS and most MS-DOS
>networks, is fine for many applications, but not for all.

It's horrible for databases, for example.   Network filesystems are designed
for reading and writing files, not for transaction processing.

>If the network gets very large and a lot of services are available which
>you will not use on a regular basis, you definitely do _not_ want to
>have them all mounted at all times, or to have to mount and dismount them
>explicitely on occasion.

Huh?  Either you have them mounted at all times or you explicitly mount them
once-in-a-while.  What other option could there possibly be.

>For instance, suppose you have a large LAN, where a single server hosts
>most of the application software. You install a new release on the server
>and that's fine. But then you have to install a license or just a 100 byte
>preference file in _every client_ node. Would you want to mount them all
>on the server, or walk to every machine with a disk, or just sit at the
>server and type something like:

LAN configuration management (I think I've got the right buzz-word) is a whole
business onto itself -- there are, for example, dozens of Netware products for
remotely upgrading applications.

>What I'm suggesting is that there should be a _standard_ syntax to reference
>remote file systems in a normal AmigaDOS path _without_ needing to mount
>them.

This is a semantic game.  You just want a mount without an associated icon or
device/volume name.

>                         Tnx for your attention

You're welcome.  It's clear that you've spent a lot of time thinking about
this, and it's always nice to hear from thinking people.  :-)

>
>---------------
>Andy Zanna                           e-mail:   SDEVAX::[e-mail]


--
Dale Larson, Software Engineer | Anyone who believes that what I say or do
                          | represents the policies or procedures of
                   | Commodore has more lawyers than they have
[e-mail]          | common sense.