Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!husc6!hao!oddjob!mimsy!umd5!trantor.umd.edu!louie
From: louie@trantor.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.amiga
Subject: Re: sources to dvi2iff, version -1; tcp/ip for amiga
Message-ID: <1929@umd5.umd.edu>
Date: Tue, 15-Sep-87 09:31:49 EDT
Article-I.D.: umd5.1929
Posted: Tue Sep 15 09:31:49 1987
Date-Received: Thu, 17-Sep-87 06:23:35 EDT
References: <503@louie.udel.EDU>
Sender: ris@umd5.umd.edu
Reply-To: louie@trantor.umd.edu (Louis A. Mamakos)
Organization: University of Maryland, College Park
Lines: 52

In article <503@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes:
>  ON a related note, i have been thinking about TCP/ip on amiga. 
>My idea is to take ed pucketts pipe device and hack it so that 
>it is wired into TCP/IP. Then TCP/IP looks like a device; we could
>call it net:. Why do this? Well, consider this mapping:
>First, call the modified pipe device net:
>Open	->	open a tcp/ip socket. You call it  "tcp.port" (e.g. tcp.25)
>                or just "ip". Returns a handle to a unique tcp or ip port
>Close	->	close the socket
>Dir	->	when applied to net:, just shows you all the open sockets.
>Delete	->	close the connection from outside the tcp/ip code
>		or the program using the socket, e.g. you could 
>		from the CLI do a DIR net:, then delete stuff 
>		you are trying to kill.
>and so on.
>
>Note that we can also allow taps on connections; useful for debugging.
>Now we can migrate telnet, ftp, and so on out of the karn code 
>into seperate processes. We can also now run rcp, rsh, and so on. 
>Each tcp/ip user will be in its own window. Looks like a win to me; 
>it is not possible on a PC or Mac because, as usual, no multi-tasking.
>In fact the karn code does a sort of multi-tasking on its own 
>because of this lack.

I've started a similar effort.  In fact, my port of the Phil Karn TCP/IP 
code to the amiga was just an intrim step to a real implementation of
an Amiga device driver.  I dropped amigatcp.tar on TRANTOR.UMD.EDU for a few
folks to play with;  I'm surprized its taken off so much.  You should fetch
the complete package (for the PC),  from LOUIE.UDEL.EDU.  It comes complete
with documentation and everything!  Note that Phil has produced new versions
that have made my port obsolete by now.  Maybe when C Ltd returns my hard
disk (#$%^#@$..) I can get some work done.

My idea was to make an EXEC device driver, "internet.device".  In fact, you
will see a stub of code in the existing version that actually does this.  I'm
not sure at this point if imbedding it in the file system is a good idea;  I
done know if the semantics of the network connection can be maintained.  How
dow you indicate CLOSE on your side of a TCP connection, yet continue to
read from the other side?  And make this work with existing applications that
use fhe file system?  Hmmm...

The code I ported was compiled with Manx C;  I've given up on Lattice a long
time ago.   The vapor 4.0 might be better, but it is a little soon to count
on it saving the day.  I understand that the next major version of Manx C
also has function prototypes (see interview in latest Amazing Computing with
Goodnow).

Anybody know about any SCSI ethernet controllers? 


Louis A. Mamakos  WA3YMH    Internet: louie@TRANTOR.UMD.EDU
University of Maryland, Computer Science Center - Systems Programming