RMXJ%CORNELLA.BITNET@ucb-vax.ARPA (10/25/85)
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???? Do all pdn's have the same problem (if there is one)? Someone claimed that this was not possible to do (using UNIX over TELENET) and I'm writing to this list to verify(?) this. Please reply directly to me as I am not on this list. Kind regards, --- Gligor Tashkovich BITNET: RMXJ @ CORNELLA INTERNET: RMXJ%CORNELLA.BITNET@WISCVM.WISC.EDU (or BERKELEY.EDU) UUCP: ...![ucbvax,psuvax1]!rmxj%cornella.bitnet
ron@BRL.ARPA (Ron Natalie) (10/25/85)
The only problem I ever had using UNIX over GTE TELENET is that TELENET is unbearably slow. -Ron
dave@lsuc.UUCP (David Sherman) (10/28/85)
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
piet@mcvax.UUCP (Piet Beertema) (11/01/85)
>4. Set up the remote PAD (using X.29) to forward a packet on > CR or any control character >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. You're lucky: lots of PADs are braindamaged in one or more respects; specifically most of them don't allow you to generate X.29 commands, so you have no control over the remote PAD... -- Piet Beertema, CWI, Amsterdam (piet@mcvax.UUCP)