|
Re: Terminal across network
by castaway (Parson) on Oct 21, 2004 at 05:33 UTC
|
There are two people, A and B. A has a problem, and attempts to explain it to B (also C, D, E and F.. ), however he leaves out half of the details..
In other words, I'm not at all sure what you're talking about. I assume this is something you want to do in Perl? What did you attempt already? code? What do you mean by 'get a terminal window'? Each logged in terminal, via local machine, ssh, telnet or otherwise, does get assigned a tty all of its own. What did you want to do with this exactly?
C. | [reply] |
|
|
I apologize if I am not able put my word across.
Let me try again. Infact, I got to boil the concept down and got to implement it in perl.
Premises: There are two machines A and B connected in network. I am talking about issue related to Network Management. For the time being, I will stick to telnet.
What normally happens when A telnets to B:-
In the command line we need to login and type password. After authentication, A is logged in to B and has access to shell of B.
What I need :-
From A, I telnet to B through script, and in response B should pop it's window or screen in Machine A. What exactly i mean is, B should spawn a thread which create a shell window in machine A. In effect, if I switch off machine B, the shell window of machine B in A should, disappear.
Till now what I have analysed is, this has something to do with XServer or a XWindow. I am clueless about how to implement it in perl.
| [reply] |
|
|
Ah, that makes some more sense. You mean you would like a window, like a normal terminal, in which the user of your script can type commands, that then happen on the machine you are connected to?
If I understood correctly now, then you don't need to start a different program to achieve this, you can just get your perl script to 'listen' on STDIN, and to the telnet socket. When the user types something in the window that the perl script is running in, the script sends it to the remote machine via the telnet socket. The answer comes back via the telnet socket, and is printed to STDOUT in the normal way. Does that make sense? And is it enough?
Coincidentally, I have written several programs of this type. im2 is one of them (but it's code is complex).
What you need are: IO::Socket::INET for the telnet connection (or maybe Net::Telnet) and IO::Select to check whether STDIN or the socket have data waiting, and deal with it appropriately.
Is that enough to start with?
C.
| [reply] |
|
|
|
|
|
Re: Terminal across network
by perlcapt (Pilgrim) on Oct 21, 2004 at 13:43 UTC
|
If I understand that A creates a process on B which is, in fact displayed on A: The display window is provided by the window server on 'A,' hence A is called the server. The process on 'B' that created the window is called the client process. Admittedly this sounds back-assward, but it is the view of the windowing system.
If, however, A creates a window on itself, and in the window it connects to B in order to run a process on B, then, from the window management point of view, A is both the server and client. From the application point of view, assuming that A's window connects to a server on B, A is the application client.
Messy, huh?
It is important to separate the windowing environment from the application environment IF THE APPLICATION IS NOT A WINDOW BASED APPLICATION. Once the distinction is made as to which is the server and which the client, then the appropriate client and server code can be written.
-ben | [reply] |
Re: Terminal across network
by gman (Friar) on Oct 21, 2004 at 14:51 UTC
|
| [reply] |