Xref: utzoo comp.sys.amiga:28009 comp.sys.amiga.tech:3274
Path: utzoo!attcan!uunet!super!udel!rochester!rutgers!mcnc!rti!sas!walker
From: walker@sas.UUCP (Doug Walker)
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Re: CheapNet (SneakerNet ?)
Message-ID: <769@sas.UUCP>
Date: 18 Jan 89 21:18:04 GMT
References: <5748.AA5748@heimat>
Reply-To: walker@sas.UUCP (Doug Walker)
Followup-To: comp.sys.amiga
Organization: SAS Institute Inc, Cary NC
Lines: 34

In article <5748.AA5748@heimat> sneakers@heimat.UUCP (Dan "Sneakers" Schein) writes:
>  I know this method is limited by allowing for only one way communications
> with no file transfer, but thats all I need. My desk is just too small for
> 2 keyboards and 2 monitors!

Why is it limited?  The interface to the parallel.device is almost identical
to the serial.device, the only exception being that you can't set flags that
don't make sense in the setup (like bps).  I am working on an AmigaDOS device
driver to allow you to access another node's devices via some arbitrary
communications medium.  I certainly would expect the parallel port to be
a prime candidate.  I have played with it a little and have run into what
may be parallel.device bugs, but the hardware is eminently capable of high-
speed two-way data transfer.  Right now I'm using DNET, but it seems to
be a little flaky about dropping my connection.

While I'm on the subject:  has anybody had the following problem with DNET?

1. Side A writes to an already-open connection.  The DWrite returns
   successfully.

2. Side B, which is doing a DRead (synchronous, not asynchronous read)
   never gets notified there is any data.

3. Side A, now getting desperate, sends a DNET EOF.

4. Side B never wakes up.

5. Side A terminates DNET.

6. You guessed it, side B never wakes up.

DNET itself is up, since I can still initiate new transfers with PUTFILES
and the like, but I can't blast that one connection loose short of sending
a BREAK signal to the DNET process on side B.