Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!DEVELOPMENT.WATSTAR.UWATERLOO.CA!erick From: erick@DEVELOPMENT.WATSTAR.UWATERLOO.CA Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: (none) Message-ID: <9106240655.AA14643@watserv1.uwaterloo.ca> Date: 24 Jun 91 06:50:31 GMT Sender: usenet@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 73 Steven L. Johnson writes: (on Joe Doupnik's comments of pc TELNET servers) > >Right idea, but incorrect in one detail that may make the project >somewhat easier. The detail: PC-Anywhere does not have to use special >encoding to make sense of the stream. It can use the terminal protocols >like VT-200, Wyse-60, or a user defined type (roll your own protocol!). I don't understand this. Do you mean handling the TELNET option negotiations? The program will have handle an NVT (Network Virtual Terminal). That device has a few guarenteed capabilites, like CR and LF (but read the RFC before you try and separate them) and usually it supports some extended protocol, typically VT100 or better. Writing to the NVT is pretty simple, with only a few execptions you can almost entirely assume VT100 (or whatever) compatibility. Writing to a TCP/IP connection is easy too. On PC Anywhere he writes: > Also it can direct this stream to the serial port, or INT 14 redirector, > a gateway PC (also a function of PCA) whose serial port could be connected > to a Telnet terminal server. On the other hand given that PCA can but > a defined terminal stream over a defined software interface (INT14), the > software-only solution might only have to provide the INT14<->TCP/IP/TELNET > link. These two solutions are similar in that they go through INT 14 or serial ports. a) PCA running though an INT 14 redirector. You don't want to do it. Every char being passed through an interrupt is not pleasant. (I have PCA III which does not support the redirector so I can't test this.) You may try patching my int14 redirector to handle everything necessary. If you do, you must rewrite the int14 part is assembly language to get better than RS232 performance. If PCA accepts one of the other int14 based standards which accept multiple characters, this may become a realistic project. +------------+ b) PC --serial--> | TCP/IP box | <--------- TELNET | w/TELNET | | server code| +------------+ I have implemented this and will probably decide against using it. In my implementation I let the installer designate a minimum interval between transmissions (collect data in the gateways buffers) If you don't do that you get too many small, wasteful packets. When you do it, keyboard i/o appears slow, scrolling is slower. It just ain't too pretty. Of course you need one pc for every four PCA machines, but you also save the cost of 3 Ethernet cards. To make it work real well you should use *full* rs232 cables and emulate modem signals. (Warm up that soldering iron.) Your PC-> gateway communications will be assuming a fixed channel capacity (9600 baud). If your user's terminal is located on the internet (probable since we are discussing this on a tcp-ip list) that fixed capacity is nonsense. PCA will take (min. approx) 1.6 seconds to update an entire screen to the gateway box. For nearby users, that box can flash those results to the remote guy in a tiny fraction of a second but it will appear extremely slow to the user because of that huge delay via serial lines. When I designed TELNETD, I made some choices which should make block opertations (like banner screens) work in a few large packets, but I give priority to updating characters near the current line. This should keep word processing and dos based users happy with acceptable response times while keeping network traffic at a reasonable level. Erick