Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!snorkelwacker!bloom-beacon!CS.TORONTO.EDU!moraes
From: moraes@CS.TORONTO.EDU (Mark Moraes)
Newsgroups: comp.windows.x
Subject: Re: Remote xterm strategy
Message-ID: <90Jan6.054031est.2293@neat.cs.toronto.edu>
Date: 6 Jan 90 10:40:28 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Reply-To: moraes@csri.toronto.edu
Organization: The Internet
Lines: 66

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...