Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!emory!mephisto!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga
Subject: Re: NET: NET: NET: NET: NET: (Is the Net: device real?)
Keywords: NET:, net:, net, NET, network, spam, spam
Message-ID: <1375@sas.UUCP>
Date: 11 Dec 89 19:01:55 GMT
References: <18897@watdragon.waterloo.edu>
Reply-To: walker@sas.UUCP (Doug Walker)
Organization: SAS Institute Inc, Cary NC
Lines: 70


I tried to mail this, but no go with our mailer (BTW, those of you who never
get a response from me - our intermittent mailer is probably the reason)

In article <18897@watdragon.waterloo.edu> you write:
>A while back, in the transactor (amiga) magazine (BTW: keep going guys,
>it's a great magazine), I read something on a NET: device.
Yes, John Toebes and I wrote the series of articles you are referring to.

>Is it real?  Is it actualy going to be sold with some product or something?
Yes, and no.  It is real, but it is going to be given away for free.  In fact,
it is already available in a form that works with Dillon's DNET and a 
parallel-port version.

>I would like to know how it functions, so I can support it in a really neat
>program I'm writing.
You don't need to support it.  As long as you support read/write to an Amiga
file system, it works.  It *IS* an Amiga file system.

If you need process-to-process communications, NET: is not what you want.
You should look into Matt Dillon's DNET package, also freely redistributable.

>o     What types of networks will this net: device work with?
>       (Ethernet? something else?  Serial link-up thing?)
Right now you have to write a driver for each type of network.  This is a 
matter of writing five functions (read 'n' bytes, write 'n' bytes,
initialize, terminate, resynchronize) of which at least the resync can
be omitted, and possibly the init and term depending on your network.
It took me about 2 hours to implement Matt's parallel port stuff, including
testing, given the code to read and write the parallel port.

Eventually I will support multiple simultaneous networking devices, allowing
you to have some network nodes mounted on, say, ethernet, and others on 
the serial port, etc.  That's planned for a future release.

>o     How much memory will the network software use?
NET: uses about 14k on the handler side, and about 12k on the server side,
plus buffer sizes.  Buffer size is currently hardwired to 8k but will
be configurable soon.

>o     Any bottlenecks in the system that slow the thing down?
The I/O rate is the only thing.  DNET at 1200 baud is pretty miserable,
the parallel port code is pretty snappy.

>o     Any security on files, directories, and stuff?
Not currently, but hopefully C= will allocate some protection bits for 
network usage.  If they do, I will implement it.

>o     Will it support muliple networks, or printing through networks, or linked
>       networks somehow?
Multiple networks, see above.   Printing through networks, quite possibly but I
haven't investigated it yet.  If I can come up with a PRT: device that looks
enough like a file system, it will work.  What we need is a STREAM: file system
that talks to stream-oriented devices like SER:, PAR: and PRT: for us;  if we
get one, it will work by simply copying the file to NET:STREAM/PAR or whatever.


>o     Cost, and minimum hardware requirements, and ideal hardware setups?
Cost: none, unless you care to make a donation.  Minimum hardware: a cable.
If you are close enough (i.e. right next to each other) a parallel port cable
will give you the best response.  If not, a serial port cable with null
modem or hookup via real modem will be necessary, but serial hookups are quite
slow.

  ***** 
 *|_o_o|\\     Doug Walker, Software Distiller
 *|. o.| ||
  | o  |//     "It is well to remember that evil is a pretty bad thing."
  ======
usenet: ...mcnc!rti!sas!walker   plink: dwalker  bix: djwalker