[comp.protocols.tcp-ip.ibmpc] FTP PC/TCP and Clarkson's NCSA Telnet living together

lance@hermix.UUCP (Lance Ellinghouse) (02/22/91)

I would like to be able to use FTP's PC/TCP and IDRIVE (TCP/IP and NFS)
while using Clarkson's version of NCSA Telnet. 

I have not figured out how to do this. 
I am running the Clarkson packet drivers for the WD8003e board and 
have Telnet configured to use them. The problem is that FTP and Telnet
don't want to use it at the same time. 

If I start Telnet while I have PC/TCP running, it will not allow me to use
the board at all. I have to unload PC/TCP to allow me to use it.

The reason I need to use CU Telnet is that I have to be able to map
my keyboard ANYWAY I need it and I have not fouind anything else that will
work well enough. 

Please if you have any ideas/sugestions as to fixing this problem,
PLEASE E-mail me.

Thanks,
Lance

 -----------------------------
|Lance Ellinghouse            |
|Mark V Systems, Ltd.         |
|hermix!lance@anes.ucla.edu   |
 -----------------------------

fks@ftp.com (Frances Selkirk) (02/23/91)

Unfortunately, it's not going to work. The packet driver sorts packets
by protocol type, and if you run two stacks of the same type (in this
case, IP) over the packet driver, one will always be starved.

There is a version of NCSA that runs with Sun's PC-NFS. I believe it
was developed to use Sun's stack. A similar version could be developed
to use our stack, but we have been unable to interest Clarkson or Brad
Clements in doing so. Fortunately, most of the features missing from
the PC-NFS telnet which people compensate for by using NCSA telnet are
included in PC/TCP's telnet (vt220 emulation, multiple connection
capability, imbedded ftp server...).  In fairness to Sun, I should
note that they are working to add many of these features. Nonetheless,
historically, their absence resulted in a strong demand for a
compatible NSCA telnet.

Lance (or any other PC/TCP users) - please write me (as fks, not info)
about what you would like to see added to, or simplified in, our
keyboard remapping (noting which version you use). I will compile a
list for development.



	

	

Frances Kirk Selkirk		 info@ftp.com	           (617) 246-0900
FTP Software, Inc.		 26 Princess Street, Wakefield, MA  01880

BRYAN@wvnvm.wvnet.edu (Jerry Bryan) (02/23/91)

>The reason I need to use CU Telnet is that I have to be able to map
>my keyboard ANYWAY I need it and I have not fouind anything else that will

???   I used to use FTP Software's TELNET heavily, and I remapped the keyboard
with no problems.  I now run OS/2 instead of DOS, so I run IBM's TCP/IP, but
back when I ran FTP Software's code on DOS the keyboard mapping was no
problem.

nelson@sun.soe.clarkson.edu (Russ Nelson) (02/24/91)

In article <210@hermix.UUCP> lance@hermix.UUCP (Lance Ellinghouse) writes:

   I would like to be able to use FTP's PC/TCP and IDRIVE (TCP/IP and NFS)
   while using Clarkson's version of NCSA Telnet. 

No can do, for two reasons, the first trivial:

1) The packet driver specification only requires a driver to deliver
   packets to a single receiver.  That means that only one protocol
   stack will ever see the IP packets.  There is software for
   Clarkson-derived packet drivers that will deliver a single packet
   to multiple receivers.  That gets us to problem 2, the serious one:

2) If you had multiple TCP stacks, which one would should the acks be
   delivered to?  Both of them?  Only the "right" one?  What happens
   if both stacks tried to glom onto the same UDP port?  Who answers
   ARP requests?

Yes, you can get this to "work" by ensuring that one of your IP stacks
uses only UDP.  Then your problems are merely terrible, as opposed to
insurmountable.  [I exaggerate the problems -- but it's still not a good
thing to do.]

--
--russ <nelson@clutx.clarkson.edu> I'm proud to be a humble Quaker.
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.

leo@unipalm.uucp (E.J. Leoni-Smith) (03/05/91)

It occurs to me that it MIGHT be possible to fudge the packet
drivers to accept IP packets on two IP addresses, and vector these
off to two different tcp/ip stacks. That would get around the
problem of the driver not being able to handle two IP stacks.

What a hack tho....