Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site lsuc.UUCP Path: utzoo!utcs!mnetor!lsuc!dave From: dave@lsuc.UUCP (David Sherman) Newsgroups: net.unix Subject: Re: Using UNIX over TELENET Message-ID: <880@lsuc.UUCP> Date: Mon, 28-Oct-85 09:56:29 EST Article-I.D.: lsuc.880 Posted: Mon Oct 28 09:56:29 1985 Date-Received: Mon, 28-Oct-85 21:21:31 EST References: <2412@brl-tgr.ARPA> Reply-To: dave@lsuc.UUCP (David Sherman) Organization: Law Society of Upper Canada, Toronto Lines: 78 Summary: you have to hack up a few things, but it can be done In article <2412@brl-tgr.ARPA> RMXJ%CORNELLA.BITNET@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@BERKELEY -- { ihnp4!utzoo pesnta utcs hcr decvax!utcsri } !lsuc!dave