saito@sdr.slb.com (Naoki Saito) (01/06/90)
Hello, folks! I'm wondering which one of the following is better for the local host when we want to remote login. (1) xterm -e rlogin remote_machine & This opens up the xterm window by the local host process. Then it just use rlogin. The same strategy as the kernel-based system such as SunView. (2) rsh remote_machine 'xterm -display localhost:0' & This invokes rsh command. A disadvantage is that .login is not executed on the remote_machine. Except the disadvantage of (2), (2) is slightly lighter(i.e. better), I think. Could you give me some comments? Is (2) really better than (1)? Is there any way to solve the disadvantage of (2)? Thanks in advance, -- Naoki Saito (saito@sdr.slb.com) Schlumberger-Doll Research
jef@well.UUCP (Jef Poskanzer) (01/06/90)
In the referenced message, saito@slb-sdr.UUCP (Naoki Saito) wrote: } (2) rsh remote_machine 'xterm -display localhost:0' & This is the method I used until recently. See the appended script for details, including .login reading and DISPLAY setting. } (1) xterm -e rlogin remote_machine & This is the method I use now. }(2) is slightly lighter(i.e. better), I think. No, I don't think so. (2) is cheaper in terms of memory used on the server machine. This was a major consideration what I was trying to bring up X11alpha on a 2 meg MacII. These days it is not a concern. Now I worry more about network efficiency, and the rlogin protocol is quite a bit more efficient than the X protocol. The only problem is, I haven't figured out a good way to get DISPLAY set correctly using the rlogin method. --- Jef Jef Poskanzer jef@well.sf.ca.us {ucbvax, apple, hplabs}!well!jef For indoor use only. - - - - - - - - - - #!/bin/csh -f # # rX - remotely execute an X command without leaving cruft behind # # Assumes login shell is /bin/csh. # # by Jef Poskanzer - version of 07feb89 switch ( $#argv ) case [01]: echo "Usage: $0 host X-cmd [args...]" breaksw default: set host="$1" shift xhost "$host" rsh "$host" "( source .login ; setenv TERM xterm ; setenv DISPLAY `hostname`:0 ; ( $* & ) ) < /dev/null >& /dev/null" < /dev/null >& /dev/null & breaksw endsw
moraes@CS.TORONTO.EDU (Mark Moraes) (01/06/90)
Quick answer -- use (2) preferably with rcmd instead of rsh, and with
xterm's -ls option for machines on the local network that you trust,
use (1) for all others.
Long winded answer for inquiring minds --
My quick-and-dirty timed tests show that starting up the xterm
remotely is usually faster than rlogin, presumably because the keycode
and refresh X communication goes as follows for the remote xterm:
X server <-> localhost kernel <+++> remotehost kernel <-> xterm <-> shell
while they go as follows for the rlogin.
X server <-> localhost kernel <-> xterm <-> rlogin <-> lh kernel <-+
+
shell <-> rlogind <-> rh kernel <-+
(replace X server with SunView in latter example, but SunView is
intimate enough with the kernel that it may have short cuts)
However, note that the X protocol is more verbose than the rlogin
protocol (32 bytes per keystroke from server to xterm, 60 bytes back
for refresh), but across a fast network (represented by +++ in the
figures) it probably doesn't matter a bit... If there's a slow point
to point link between them, this may make a difference.
Also, in the former case, X packets have to fly from remote xterm to
local host for things like popping up menus, screen refreshes, etc.
So if the remote host is less powerful than the local one, or has less
memory, or pages more, etc, it may be preferable to let the local
xterm do refreshes. (This also means you have to consider the link
bandwidth -- popping up a menu or doing a refresh means a lot of X
packets flying back and forth. Especially for the menu)
So, I use
> (1) xterm -e rlogin remote_machine &
for machines which are slow for some reason
or for machines I don't trust in my .rhosts (so I need the rlogin to
prompt for password -- I then start up all applications at the remote
end from a script. My .login uses utmp to try and determine what
remote host I'm logged in from and intuit the DISPLAY accordingly.
Gets it right half the time, sigh. The right thing to do is probably
to hack on rsh/rlogin to do something intelligent about DISPLAY...)
> (2) rsh remote_machine 'xterm -display localhost:0' &
> This invokes rsh command. A disadvantage is that .login is not
> executed on the remote_machine.
You can get .login/.profile executed on the remote machine by saying
xterm -ls. I use this for remote machines that I trust with .rhosts and
that are fast. Except that rsh will leave an rsh and rshd hanging at
either end till the xterm finishes. I use the shell script rcmd (in
R4/contrib/clients/xplaces/{rcmd,rcmd.man}) to avoid that (and
transmit DISPLAY across transparently, and do an xhost -- essentially
transparently start up remote X commands provided your .rhosts file
works and you run it from the local machine). Other people have
programs (rxexec or suchlike that do similar things)
So I would use
rcmd remote_machine xterm -ls
or
rcmd remote_machine xshell
or suchlike...rlk@THINK.COM (Robert L. Krawitz) (01/07/90)
Date: 6 Jan 90 07:04:30 GMT From: snorkelwacker!apple!well!jef@bloom-beacon.mit.edu (Jef Poskanzer) The only problem is, I haven't figured out a good way to get DISPLAY set correctly using the rlogin method. You need my xdsp script, and the code in my .login file: BTW, the fact that the .login code checks for both xt?. and xt. has some history; it isn't terribly important now. xdsp (note that this requires a variable XDISPLAY that contains your "real" DISPLAY variable, since it's usually unix:?.? on your local machine. It relies upon the fact that TERM is passed across rlogin and rsh. A similar hack works for some versions of telnet.): #!/bin/sh TERM=xtu.$XDISPLAY export TERM exec rsh $* Put this in your .login: # This hair unpacks the TERM variable into DISPLAY if (($TERM =~ xt?.*) || ($TERM =~ xt.*)) then setenv DISPLAY `echo $TERM | sed 's/xt[^.]*\.//'` setenv XDISPLAY $DISPLAY echo $DISPLAY | egrep '.*:[0-9]\.[0-9]$' >& /dev/null set term = xterm setenv TERM xterm endif ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111
casey@gauss.llnl.gov (Casey Leedom) (01/07/90)
Mark Moraes explained the trade offs between the two methods well, but
forgot a couple of performance issues. Expanding slightly on Mark's
diagrams we see some really gross details exposed:
Case 1: rsh remote-host xterm -display local-host:0
---------------------------------------------------
type: X -- lh(net) === rh(net) -- xterm -- rh(pty) (*) -- sh/app
echo: sh/app -- (*) rh(pty) -- xterm -- rh(net) === lh(net) -- X
Case 2: xterm -e rlogin remote-host
-----------------------------------
type: X -- lh(unix) -- xterm -- lh(pty) -- rlogin1
-- lh(net) === rh(net) -- rlogind2 -- rh(pty) (*) -- sh/app
echo: sh/app -- (*) rh(pty) -- rlogind1 -- rh(net) === lh(net)
-- rlogin2 -- lh(pty) -- xterm -- lh(unix) -- X
Key:
----
-- User/kernel context switch.
=== Network transfer.
lh Local-host kernel.
rh Remote-host kernel.
(pty) Kernel pseudo tty service.
(net) Kernel networking service.
(unix) Kernel UNIX domain networking service.
X X server running on local host.
xterm An xterm client. Running on the local-host in case 1.
Running on the remote host in case 2.
rlogin1 Rlogin process running on local-host. Reads from local
xterm via pty interface in CBREAK or RAW mode. Writes to
rlogind2 on remote-host.
rlogin2 Rlogin process running on local-host. Reads from rlogind1
on remote-host. Writes to local xterm via pty interface
in CBREAK or RAW mode.
rlogind1 Rlogin daemon process running on remote-host. Reads from
sh/app via pty. Writes to rlogin2 on local-host.
rlogind2 Rlogin daemon process running on remote host. Reads from
rlogin2 on local host. Writes to sh/app via pty.
(*) Sh/app and associated context switch not involved except
at carriage return if shell/application is in line
editing mode.
Analysis of case 1:
-------------------
Typically two context switches on local-host and four on remote-host
per typed and echoed character when sh/app in line editing mode.
(Two more context switches per typed and echoed character on
remote-host when sh/app in non line-editing mode.) One user process
executing on each of local-host (X) and remote-host (xterm) in
typical, line editing mode. I.e. no user process to user process
context switches involved.
Analysis of case 2:
-------------------
Typically ten context switches on local-host and four on remote-host
per typed and echoed character when sh/app in line editing mode.
(Two more context switches per typed and echoed character on
remote-host when sh/app in non line-editing mode.) Four user
processes executing on local-host (X, xterm, rlogin1, rlogin2) and
two on remote-host (rlogind1, rlogind2). I.e. lots of user process
to process context switching.
Also, all characters are forced to go through mainly inactive pty
code in the local kernel since the local rlogin has put the pty
interface between itself and the xterm into CBREAK mode (RAW mode
if the rlogin -8 switch is used).
Additionally, as Mark mentioned, the larger network packet size for the
X11 protocol versus the rlogin protocol isn't going to make much
difference. The number of packets transmitted and the inter-packet
spacing are usually the most important features of protocol performance
with respect to Ethernet. I.e. how much packet room does the protocol
leave? In this case, the size difference of the X11 and rlogin protocols
is meaningless. I think there's only one packet pair per typed and
echoed character using an xterm. If this is so, the total network impact
difference between an rlogin versus an xterm connection is probably
nearly unmeasurable.
Summary and conclusions:
------------------------
Case 1: executing an xterm on a remote host.
versus
Case 2: using rlogin to remote-host from within a locally executing
xterm window.
Case 2 causes significantly more context switching on the local-host
(ten versus two). Worse that context switching is among four different
user processes instead of only one. Even the remote-host which doesn't
see any more context switching is forced to context switch between two
user level processes instead of only one.
Not having made any actual performance timings it's impossible to make
any conclusions. But you look at the circuit and tell me that you expect
case 2 to be faster over anything except the slowest networks.
Caseyhakanson@ogicse.ogc.edu (Marion Hakanson) (01/07/90)
In article <90Jan6.054031est.2293@neat.cs.toronto.edu> moraes@csri.toronto.edu writes: >Quick answer -- use (2) preferably with rcmd instead of rsh, and with >xterm's -ls option for machines on the local network that you trust, >use (1) for all others. There's also xrsh, in R4/contrib/clients/xrsh/, which does pretty much the same thing as rcmd. A quick scan convinces me that rcmd is fancier, but xrsh should win a footrace (and start up a lot fewer processes). Choose your poison.... -- Marion Hakanson Domain: hakanson@cse.ogi.edu UUCP : {hp-pcd,tektronix}!ogicse!hakanson
barmar@think.com (Barry Margolin) (01/08/90)
Most of the people here use the "xterm -e rlogin host" method for remote
xterms, while I use the "rsh host xterm" method. My favorite complaint
about the former is the fact that the use of rlogin isn't transparent --
you have to be careful when typing "~", particularly when using rlogin from
within that window (if you type "~." instead of "~~." you kill the whole
xterm).
Of course, the solution to this is to specify "-e <untypable char>" in the
rlogin line. The strange thing is that no one here seems to do this.
--
Barry Margolin, Thinking Machines Corp.
barmar@think.com
{uunet,harvard}!think!barmarspike@world.std.com (Joe Ilacqua) (01/08/90)
You can reduce the number of process you have hanging around
by doing something like:
rsh host -n xterm -ls -display $DISPLAY '>&/dev/null </dev/null&'
The magic incantations "-n" and "'>&/dev/null </dev/null&'"
cause rsh(1C) to exit. This leave you with just the xterm and the
shell it started, and gets rid of the rsh and the shell rsh used to
start xterm.
Is this faster? I couldn't say...
->Spike
--
"The World" - Public Access Unix - +1 617-739-9753 24hrs {3,12,24}00bpsdce@smsc.sony.com (David Elliott) (01/08/90)
In article <32711@news.Think.COM> barmar@think.com (Barry Margolin) writes: >Of course, the solution to this is to specify "-e <untypable char>" in the >rlogin line. The strange thing is that no one here seems to do this. I don't know about your rlogin, but on the standard BSD rlogin, -e is followed immediately by the character to use, and if none is given, the escape feature is turned off. In other words, just use -e with no character and it will do what you expect. The reason that people don't generally do this is that it's yet another strange Unix-ism (like ZZ or W or $ in vi). Some people would rather deal with the ~ problem than to do it right. Heck, you can even point out obvious bugs in programs to some people and hand them the fix and they won't use it. -- David Elliott dce@smsc.sony.com | ...!{uunet,mips}!sonyusa!dce (408)944-4073 "But Pee Wee... I don't wanna be the baby!"
casey@gauss.llnl.gov (Casey Leedom) (01/08/90)
| From: dce@Sony.COM (David Elliott) | | [With] standard BSD rlogin, -e is followed immediately by the character | to use, and if none is given, the escape feature is turned off. In other | words, just use -e with no character and it will do what you expect. "-e" by itself won't turn off the rlogin escape character. It sets the escape character to '\0'. You can still escape out of the rlogin with ^@^Z, for instance. The following patch to the 4.3BSD rlogin client will implement the semantics you've described (I've been using this patch for the last six months with no problems): *** rlogin.c-dist Sun Mar 30 16:39:06 1986 --- rlogin.c Thu Jun 29 18:25:22 1989 *************** *** 289,295 **** */ if (bol) { bol = 0; ! if (c == cmdchar) { bol = 0; local = 1; continue; --- 289,295 ---- */ if (bol) { bol = 0; ! if (cmdchar && c == cmdchar) { bol = 0; local = 1; continue;
casey@gauss.llnl.gov (Casey Leedom) (01/08/90)
| From: per@erix.ericsson.se (Per Hedeland) | | > From: casey@gauss.llnl.gov (Casey Leedom) | > | > Even the remote-host which doesn't see any more context switching is | > forced to context switch between two user level processes instead of only | > one. | | To be perfectly fair, there is only one rlogind process running on the | remote host, handling both directions. Hhmmm. I'm sorry. I could have sworn I remembered two rlogind processes. I guess I'm going to have to slow down my output here. I'm making way too many mistakes. (You don't want to hear about it.) In any case, I see that Per is right. Rlogind uses select(2) to keep track of both the master side of the pty and the network connection instead of having separate reader and writer processes as is used by rlogin. I don't know why rlogin doesn't do this also. It's quite possible that there's no reason other than history. Note that this means that most, if not all, of the performance difference between Case 1: xterm -e rlogin remote-host Case 2: rsh remote-host xterm -display local-host:0 is going to be on the local-host since the remote-host runs the same number of processes and experiences [roughly] the same number of context switches in either case. Things that *might* make case 2 perform better than case 1 include: 1. Slow network: Extra bytes in the X protocol versus the rlogin protocol. 2. Slow network and/or slow remote-host: Extra transfers across the net caused by mouse entry/exit and other possible X events that wouldn't be experienced with case 2. These extra transfers also cause more context switches on the remote host. 3. Slow remote-host: Xterm *may* be significantly more CPU hungry than rlogind. (I have no idea one way or the other whether this may be true.) Casey
mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) (01/08/90)
> Rlogind uses select(2) to keep track of both the master side of the > pty and the network connection instead of having separate reader and > writer processes as is used by rlogin. I don't know why rlogin > doesn't do this also. It's quite possible that there's no reason > other than history. Using two processes allows you to suspend the input side without affecting the output side. This suspends the rlogin but still allows you to see remote output. (How do you do it? ~^Y, or whatever your delayed-suspend character is set to. Most people don't seem to be aware that rlogin can do this.) > Note that this means that most, if not all, of the performance > difference between > Case 1: xterm -e rlogin remote-host > Case 2: rsh remote-host xterm -display local-host:0 > is going to be on the local-host since the remote-host runs the same > number of processes and experiences [roughly] the same number of > context switches in either case. Things that *might* make case 2 > perform better than case 1 include: > 1. Slow network: Extra bytes in the X protocol versus the rlogin > protocol. > 2. Slow network and/or slow remote-host: Extra transfers across > the net caused by mouse entry/exit and other possible X events > that wouldn't be experienced with case 2. These extra transfers > also cause more context switches on the remote host. > 3. Slow remote-host: Xterm *may* be significantly more CPU hungry > than rlogind. (I have no idea one way or the other whether this > may be true.) All three of those things would make case 1 perform better than case 2, not the other way around. I don't know specifically about xterm. However, I have my own terminal emulator program, which I *suspect* is leaner than xterm (certainly smaller and simpler). Using this, I find that a local emulator plus an rlogin is easier on the remote host than a remote terminal emulator. (The remote-host in question is an overloaded VAX/750, whereas the local-host is a Sun-3 with ample spare CPU.) As for slow networks, it depends on what sort of slowness it is. I once used both an rlogin and an xterm over a network link with high bandwidth but also high delay (round-trip times on the order of two seconds), and there really wasn't much difference. (I would certainly expect a low-bandwidth link to produce different effects.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
rlk@THINK.COM (Robert L. Krawitz) (01/08/90)
One thing I notice everyone talking about in terms of this problem is
the number of {context switches,bytes,packets} per input keystroke. I
submit that, particularly on a fast workstation, a more important
criterion in many cases is the amount of load measured in (insert your
favorite here) per line, or per number of bytes, of output.
On a fast machine (such as any of the new RISC workstations), it's
impossible to type fast enough to make the machine notice (a fast typist
types at 100 WPM, which is less than 9 characters per second). Even ten
context switches per keystroke is only 90 per second, which isn't hard
to maintain. Given that users of an X-based editor don't normally type
large quantities of text into an xterm, the sustained overhead is
somewhat less. It's also impossible to type into more than one window
at any one time. However, it's very easy for a program or three to spit
out data at a very high rate. Then the issue becomes network traffic
(rlogin consumes much less than X) vs. local context switches (the
remote xterm does many fewer).
A very useful program that no one's written is xrlogin (or xtelnet, or
xsupdup). This combines xterm and rlogin in one process (it speaks
rlogin protocol itself), and does not allocate a pty on the local
machine. On the other hand, it requires a host to be specified on the
command line. Given that a major use of xterm is to rlogin to a remote
machine, this would seem a very useful program to me...
ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St.
bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142
harvard >>>>>> . Thinking Machines Corp. (617)876-1111jjd@bbn.com (James J Dempsey) (01/09/90)
For people interested in using "Method 2" (rsh otherhost xterm) you might check out the "xon" script on tape-2 in contrib/clients/scripts/xon.sh. It works no matter what type of shell you run on the local host or the remote host. It is careful not to leave any bogus zombie processes around. It does an automatic xhost to the other system and it provides a -debug option which allows you to see any errors that might have occurred (which you wouldn't see normally because of redirecting output to /dev/null). To use it you say something like: xon otherhost command arg1 arg2 Which would start up command on otherhost with arg1 and arg2 as arguments after doing an xhost and setting DISPLAY correctly on the remote host. --Jim Dempsey-- jjd@bbn.com
phil@BRL.MIL (Phil Dykstra) (01/09/90)
> Rlogind uses select(2) to keep > track of both the master side of the pty and the network connection > instead of having separate reader and writer processes as is used by > rlogin. I don't know why rlogin doesn't do this also. It's quite > possible that there's no reason other than history. For what it's worth, I once implemented a single process rlogin client via select. The sad fact was that it ended up slower (i.e. more sys time) than the two process version! Select turns out to be a pretty expensive syscall - more expensive than the single sided sleep/wakeups of the two process version. Studying the kernel code convinced me that gprof wasn't lying, so we never installed the new one. Sigh. [This was 4.3BSD on a Vax 780 about two years ago. You mileage may vary, especially based on your machine's context switch overhead.] - Phil
gerber@sushi.Solbourne.COM (Andrew Gerber) (01/09/90)
This shell script was found in /usr/bin/X11/rcmd on my machine here;
I'm not sure if it's part of the normal X distribution, but it solves
the "extra rsh hanging around" problem and in a easy-to-use way.
-------cut here--------
#! /bin/sh
# This command runs a command remotely in the background, by pointing
# stdout and stderr at /dev/null. (Should we point stdin at /dev/null too?)
# By running this through the Bourne shell at the other end, and
# we get rid of the rsh and rshd which otherwise hand around at either
# end. Hacked from a posting by clyde@emx.utexas.edu to list.xpert
if test $# -lt 2 ; then
echo Usage: $0 remotehost remotecommand
exit 1
else
host=$1
shift
fi
echo "($*)" '> /dev/null 2>&1 &' | rsh $host /bin/sh &
--------
--
/ Andrew S. Gerber / Solbourne Computer, Inc /
/ gerber@solbourne.com / 1900 Pike Rd, Longmont, CO 80501 /
/ ...!{sun,boulder}!stan!gerber (303) 678-4606 /casey@gauss.llnl.gov (Casey Leedom) (01/10/90)
| From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse) | | > Note that this means that most, if not all, of the performance | > difference between | > | > Case 1: xterm -e rlogin remote-host | > Case 2: rsh remote-host xterm -display local-host:0 | > | > is going to be on the local-host since the remote-host runs the same | > number of processes and experiences [roughly] the same number of | > context switches in either case. Things that *might* make case 2 | > perform better than case 1 include: | > ... | | All three of those things would make case 1 perform better than case 2, | not the other way around. I know. I got mixed my words up. Sorry. | I don't know specifically about xterm. However, I have my own terminal | emulator program, which I *suspect* is leaner than xterm (certainly | smaller and simpler). Using this, I find that a local emulator plus an | rlogin is easier on the remote host than a remote terminal emulator. Interesting.
casey@gauss.llnl.gov (Casey Leedom) (01/10/90)
| From: rlk@THINK.COM (Robert L. Krawitz) | | On a fast machine, it's impossible to type fast enough to make the | machine notice (a fast typist types at 100 WPM, which is less than 9 | characters per second). Even ten context switches per keystroke is only | 90 per second, which isn't hard to maintain. But what happens if you have ten, twenty or thirty people operating in that mode. Say, for instance, you're using a nice fast central machine like a Mips 6280 and your users have X terminals ... I think it could get pretty vicious ...
jim@bahamut.fsc.com (James O'Connor) (01/10/90)
In article <1990Jan5.184224.7960@sdr.slb.com>, saito@sdr.slb.com (Naoki Saito) writes: > (2) rsh remote_machine 'xterm -display localhost:0' & > This invokes rsh command. A disadvantage is that .login is not > executed on the remote_machine. > > Except the disadvantage of (2), (2) is slightly lighter(i.e. better), I think. > Could you give me some comments? Is (2) really better than (1)? Is there any > way to solve the disadvantage of (2)? Since a user who wanted to use (2) would probably have a home directory on the remote machine, that user could create a shell script in that directory containing: . /u/whoever/.profile xterm & and then run it with "rsh remote_machine 'DISLPAY=localhost:0 shell_script'" This should add a advantage in that the rsh will not get left in the background like it would under (2). Also, HP's hpterm has an option which causes hpterm to start the shell with a "-" prepended so that it will read the "login" files on it's own. I remember checking the man page for xterm, but I don't remember if it has this option as well. ------------- James B. O'Connor Work: jim@tiamat.fsc.com Data Processing Manager Play: jim@bahamut.fsc.com Ahlstrom Filtration, Inc. UUCP: uunet!tiamat!jim
ken@hpubrcf.HP.COM (Ken Green) (01/10/90)
> A very useful program that no one's written is xrlogin (or xtelnet, or > xsupdup). This combines xterm and rlogin in one process (it speaks > rlogin protocol itself), and does not allocate a pty on the local > machine. On the other hand, it requires a host to be specified on the > command line. Given that a major use of xterm is to rlogin to a remote > machine, this would seem a very useful program to me... I tackled this problem rather differently.... I wrote a simple remsh ( rsh ) type command that doesn't keep daemon processes lying around. You then just ask the remote system to throw you back an xterm window. My workstation currently has 73 windows started by remote users and I sure didn't want the overhead of running 73 remshd. The other thing I found useful was to take over all the enviroment variables. ( Not so usefull between different system types, but a great boon that the DISPLAY variable goes ). Ken 'Now I just need more memory' Green
rlk@THINK.COM (Robert L. Krawitz) (01/10/90)
Date: 10 Jan 90 00:13:43 GMT
From: gauss.llnl.gov!casey@lll-winken.llnl.gov (Casey Leedom)
But what happens if you have ten, twenty or thirty people operating in
that mode. Say, for instance, you're using a nice fast central machine
like a Mips 6280 and your users have X terminals ... I think it could
get pretty vicious ...
Point well taken. I'm thinking in terms of desk-based compute power (e.
g. a 4/60), with a single user. Of course, I've never been too keen on
X terminals, which may explain my position on this...aperez@cvbnet.UUCP (Arturo Perez x6739) (01/18/90)
From article <32711@news.Think.COM>, by barmar@think.com (Barry Margolin): > > Most of the people here use the "xterm -e rlogin host" method for remote > xterms, while I use the "rsh host xterm" method. My favorite complaint > about the former is the fact that the use of rlogin isn't transparent -- > you have to be careful when typing "~", particularly when using rlogin from > within that window (if you type "~." instead of "~~." you kill the whole > xterm). I use rsh host xterm because then when I resize the xterm (which I do fairly often), the row and columns information is transmitted correctly. If I use xterm -r rsh host I have to manually do stty rows xx columns yy in order to get more, vi, et al to work correctly. Arturo Perez ComputerVision, a division of Prime aperez@cvbnet.prime.com Too much information, like a bullet through my brain -- The Police
barmar@think.com (Barry Margolin) (01/18/90)
In article <373@cvbnet.Prime.COM> aperez@cvbnet.UUCP (Arturo Perez x6739) writes: >I use > rsh host xterm >because then when I resize the xterm (which I do fairly often), the >row and columns information is transmitted correctly. The 4.3bsd version of the rlogin protocol transmits window size changes. Rlogin sets up a SIGWINCH handler and sends an out-of-band message with the new window size. When rlogind receives this control sequence it performs an ioctl() of the pty to set the window size, which causes the process on the other end of the pty to get a SIGWINCH. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar