Introduction About Site Map

RSS 2 Feed RSS 2 Feed

Main Page | Blog Index

Sunday, October 30th, 2005, 2:42 pm

Cross-Platform Remote Access

Multiple SSH sessions
Dozens of remote sessions occupying a cluster. Terminals shaded on the left monitor (click to enlarge)

WHATEVER operating system we use, the idea of using remote terminals should not be foreign to us. These days, it is rather common to log on to a computer remotely and manage it from afar as if we were actually there.

Inter-Platform Connections

Windows users frequently stick to VNC, which requires a high-bandwidth connection and grabs the entire desktop/workspace metaphorically ‘across the wire’. Nonetheless, there are some smart algorithms (c/f Citrix clients), which only re-draw elements once they change, so speed/bandwidth might not be the utmost concerns.

Linux users, on the other hand, are capable of establishing transparent connections with Windows machines via VNC, for which there are many applications in existence (Remote Desktop or rdesktop among several more variants). Linux also takes a different approach in its most natural method for remote access. Take, for example, SSH connections wherein individual windows get ‘grabbed’ and communicated over the network, only upon demand. Everything else should be managed from the command-line interface (CLI), e.g. bash and xterm. This might be less natural to the majority of users nowadays, especially to those unfamiliar with CLI’s.

Windows connectivity to *nix protocols can be established using the renowned PuTTY. In the case of Telnet or RLogin, applicability might be slightly different, but merely all protocols seem to have been covered. In fact, Windows typically supports telnet at its core (Start » Run... » telnet » ENTER). This establishes a somewhat mutual relationship. Windows users can remotely log in to Linux machine (might need a commercial X-session if not CygWin) and Linux users can connect to Windows hosts. In modern Linux distribution, all necessary toolsets are already pre-installed from what I can gather.

Extreme Use of Remote Access

When carrying out some computer vision experiments, I was at times using over 30 Pentium 4′s. These were used for quite a considerable overnight resource hogs. The communication barrier was merely inexistent; I an fortunate enough to work upon a 100Mbit Ethernet backbone. To give some indication of how fast the connection actually is, I can transfer an entire CD (~650 MB) across campus in less than a minute. That unbelievable speed is at times truly needed. I estimate that I use up bandwidth of over 100 GB per month, mainly due to backup necessities.

As regards extreme use of remote login, this is one of the most exciting experiences, to me at least. Rather than conducting large-scale experiments over the period of one month on a single CPU, they can be distributed, thus completed within a day. Nothing can beat that in terms of productivity. AI is known to be resources-greedy. Our computer vision methodology falls under that branch too. I will soon write about the use of supercomputers to run my experiments, albeit this is still under negotiation.

Traffic Chain

I could no longer resist my geek spirit so I decided to experiment with the idea of SSH chaining. The dependency of one machine upon another is something that intrigues me, so often I log in remotely to one machine, which in turn connects to another.

I decided to set up a larger SSH chain wherein I connect to my own computer via an entire ‘ring’ of machines, using SSH. I wanted to see how this affects speed and responsiveness in applications that ‘travel’. Needless to mention, this also cripples all computers in that ring. This observation has some interesting implications on its own. These intermediatory machines can be perceived as purposeless routers. If one computer in the chain is reset, the whole chain collapses and the connection is lost. It may also take a while to re-build, which to me at least, is amusing.

Cluster Control

On to some more extreme uses of SSH, some time ago I read about use of SSH to control entire computer clusters in parallel. In essence, the user will be sending any given command to an ‘army’ of computers (clients or computational hosts). The tool is not very flexible, but can be valuable under particular circumstances.

Comments are closed.

Back to top

Retrieval statistics: 21 queries taking a total of 0.130 seconds • Please report low bandwidth using the feedback form
Original styles created by Ian Main (all acknowledgements) • PHP scripts and styles later modified by Roy Schestowitz • Help yourself to a GPL'd copy
|— Proudly powered by W o r d P r e s s — based on a heavily-hacked version 1.2.1 (Mingus) installation —|