Using UNIX over TELENET

[David Sherman]

In article <2412 at brl-tgr.ARPA> RMXJ%CORNELLA.BITNET at ucb-vax.ARPA writes:
>
>Are there any (preferably documented) problems with using
>the UNIX Operating System (which, in this case, is acting as a
>front-end to a supercomputer) over the TELENET pdn????

I've never seen any documentation. I came up with my own solutions.

Our site (lsuc, the Law Society of Upper Canada) is accessible
through Datapac, the Canadian packet-switched network. The machine
is in Toronto, while the users include staff and students in Ottawa and
London, Ontario, as well as law students who are articling all
over the province. (There are 28 Datapac nodes in Ontario and
almost all of them have been used by students connecting to our system.)

The principal problems relate to echoing and the fact that the
user doesn't send a packet with every character. Transmitting single-char
packets would be horrendously expensive; the usual pdn standard
is to transmit only when the user presses RETURN.

The core of what you do is modify UNIX so it doesn't echo, but
instructs the user's PAD (to which he's connected in the city
in which he dials up the network) to echo, where necessary.

Here are some of the things I had to do (to v7 UNIX):

1. Modify getty to understand a new code which means "this is
   a PAD line"; it leaves echoing off when it invokes login.

2. Modify getpass() and recompile the things that use it (su,
   passwd, login, newsgrp, crypt) to use my new echoon() and
   echooff() routines.

3. Write echoon() and echooff() to check /etc/ttys to see if
   we're on a PAD line; if we are, then instead of using
   ioctl, it simply writes the appropriate X.29 instruction
   to our PAD, which instructs the remote PAD to turn echoing
   on or off as required.

4. Set up the remote PAD (using X.29) to forward a packet on
   CR or any control character; this let's any reasonable
   user-selected interrupt key work, including DEL, CTRL-C
   and CTRL-\ for quit. (Slight drawback: backspaces send
   the packet, so someone who mistypes and corrects a lot
   costs you more money.)

5. Change all applications software used by our students so
   that nothing runs in cbreak mode; that is, CR is required
   before anything will respond.

6. Make sure that staff know not to try and use a full-screen
   editor like vi; we simply use (an enhanced) "ed" and, for the
   more advanced, its superset "qed".

7. Modify any applications programs around which put the user
   into noecho mode so that, when they're finished, they check
   the original tty settings instead of blindly assuming that
   echoing should be turned back on.

>Do all pdn's have the same problem (if there is one)?

Unless you can afford to pay for one-character packets, and
have FAST network turnaround, you'll have the cbreak and echoing
problems.

Incidentally, our setup has been running fine for over a year,
and has had heavy staff and student use. We have a 12-channel
Micom X.25 PAD. Our machine is a Perkin-Elmer 3220 running
"Edition VII Workbench" (v7). Anyone who wants further details,
feel free to contact me.

Dave Sherman
The Law Society of Upper Canada
Toronto
(416) 947-3466
ARPA: ihnp4!utzoo!lsuc!dave at BERKELEY
-- 
{  ihnp4!utzoo  pesnta  utcs  hcr  decvax!utcsri  }  !lsuc!dave