Using UNIX over TELENET
David Sherman
dave at lsuc.UUCP
Tue Oct 29 00:56:29 AEST 1985
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
More information about the Comp.unix
mailing list