Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!clarkson!grape.ecs.clarkson.edu!nelson From: nelson@sun.soe.clarkson.edu (Russ Nelson) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: FTP on a non-ethernet LAN Message-ID: Date: 4 Feb 91 03:18:50 GMT References: <1991Feb3.085247.1922@cho006.cho.ge.com> Sender: @grape.ecs.clarkson.edu Reply-To: nelson@clutx.clarkson.edu (aka NELSON@CLUTX.BITNET) Organization: Clarkson University, Potsdam NY Lines: 31 In-Reply-To: newman_r@cho006.cho.ge.com's message of 3 Feb 91 12:52:47 GMT In article <1991Feb3.085247.1922@cho006.cho.ge.com> newman_r@cho006.cho.ge.com writes: I'm looking for ways to implementing a PC to PC file transfer mechanism over a non-ethernet LAN, and it seems like TCP/IP would be a natural for this. Specifically, I was thinking of using NCSA Telnet as the PC application software, and writing a packet driver to provide the interface to the LAN hardware. My question for the net: `is this a reasonable approach?', Yes. There are two ways to do it: 1) You can lie, and claim that your packet driver interfaces to Ethernet. This can be easy to do if your network allows packets as large as 1514 bytes. It can also violate the layering concept, which can make your life more difficult. 2) You can invent a new kind of packet type, and modify NCSA Telnet so that it can access this new packet type. I suggest you start with a version of NCSA Telnet that also supports SLIP packet drivers, because the code to handle multiple packet driver types will already be there. and if so, where can I find the specifics for Telnet/packet driver interface? vax.ftp/com:pub/packet-driver.ascii -- --russ Humble Quaker, and damned proud of it. It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.