RemoteConsoleUtil design
37 views
Skip to first unread message
Andreas Rønning
Sep 25, 2011, 12:29:30 PM9/25/11
to DConsole
A common request is the ability to control an instance of DConsole via
another. This is primarily useful for managing DConsole instances
running on hardware with no keyboard attached, or remote
administration and debugging.
To meet this demand, we've had prototyping and discussion between
myself and Juan Delgado, but as with most things we reach a point
where our particular demands are in a sense virtual, and we have to
start thinking about the broader implications of what we are
implementing.
Our current design, which is very much in flux, works as described:
1. A client -or slave- console registers the SlaveConsoleUtil plugin.
2. The SlaveConsoleUtil plugin looks for a local configuration xml
file, which contains a hostname.
3. A server -or master- console registers the MasterConsoleUtil
plugin.
4. The MasterConsoleUtil expects AIR classes, and through ServerSocket
implements a rudimentary socket server.
5. When the SlaveConsoleUtil detects the MasterConsoleUtil server
running at the specified hostname, it establishes a connection and
receives a unique identifier local to the Master.
6. From this point on, the slave pipes all logging messages to the
master, which prints them with a tag prefix equal to the slave's
unique identifier.
* ie. 0:MyClass > Hello master!
7. When a slave has connected with the master, the master can set the
slave as its current commandline target with the setCurrentSlave
command
' ie. setCurrentSlave 0
8. While a slave has been targeted in this fashion, autocomplete for
the master is disabled, and all master commandline input is executed
on the slave, which spits logging responses back to the master.
9. To return commandline control to the master console as usual, hit
the escape key.
This has been implemented rapidly and performs as intended. We have
obvious and immediate challenges, however.
First of all, the distinction between master and slave is conceptually
solid but logically vague.
Why is it a given that the master is running the server? In this way
the slave is forced to be aware of a fixed master hostname, which is
impractical across networks. Perhaps the slave should be the one
running the server? But what of cases where this behavior is
prohibited?
Why does a master console need to be the one to connect to a slave?
Shouldn't we be able to simply telnet in via terminal and do our
business that way?
I'm interested in hearing people's opinions on this functionality, so
we can have a better idea of what direction to take it and meet at
least the lowest common denominator. Personally I would love to be
able to abstract away the server and be able to have it running both
on the slave AND the master, so as to best facilitate a more general
protocol based approach where telnetting into a slave could be a
viable option.
another. This is primarily useful for managing DConsole instances
running on hardware with no keyboard attached, or remote
administration and debugging.
To meet this demand, we've had prototyping and discussion between
myself and Juan Delgado, but as with most things we reach a point
where our particular demands are in a sense virtual, and we have to
start thinking about the broader implications of what we are
implementing.
Our current design, which is very much in flux, works as described:
1. A client -or slave- console registers the SlaveConsoleUtil plugin.
2. The SlaveConsoleUtil plugin looks for a local configuration xml
file, which contains a hostname.
3. A server -or master- console registers the MasterConsoleUtil
plugin.
4. The MasterConsoleUtil expects AIR classes, and through ServerSocket
implements a rudimentary socket server.
5. When the SlaveConsoleUtil detects the MasterConsoleUtil server
running at the specified hostname, it establishes a connection and
receives a unique identifier local to the Master.
6. From this point on, the slave pipes all logging messages to the
master, which prints them with a tag prefix equal to the slave's
unique identifier.
* ie. 0:MyClass > Hello master!
7. When a slave has connected with the master, the master can set the
slave as its current commandline target with the setCurrentSlave
command
' ie. setCurrentSlave 0
8. While a slave has been targeted in this fashion, autocomplete for
the master is disabled, and all master commandline input is executed
on the slave, which spits logging responses back to the master.
9. To return commandline control to the master console as usual, hit
the escape key.
This has been implemented rapidly and performs as intended. We have
obvious and immediate challenges, however.
First of all, the distinction between master and slave is conceptually
solid but logically vague.
Why is it a given that the master is running the server? In this way
the slave is forced to be aware of a fixed master hostname, which is
impractical across networks. Perhaps the slave should be the one
running the server? But what of cases where this behavior is
prohibited?
Why does a master console need to be the one to connect to a slave?
Shouldn't we be able to simply telnet in via terminal and do our
business that way?
I'm interested in hearing people's opinions on this functionality, so
we can have a better idea of what direction to take it and meet at
least the lowest common denominator. Personally I would love to be
able to abstract away the server and be able to have it running both
on the slave AND the master, so as to best facilitate a more general
protocol based approach where telnetting into a slave could be a
viable option.
Juan Delgado
Sep 25, 2011, 12:53:21 PM9/25/11
to DConsole
Yoyoyo!
As previously discussed. I'm ok with a simple IP / port mechanism that
works by default, as long as it's easy to overwrite. In my current
project the implementation on the proof of concept wouldn't work.
About which one runs the server... that's good question. Surely having
the slave running the server simplifies connecting to it (since most
likely you know the IP), but what about security? We could password
protect it somehow with a password read at runtime.
And I agree, abstract the server and being able to run it on both
master and server sounds like a good idea.
J
As previously discussed. I'm ok with a simple IP / port mechanism that
works by default, as long as it's easy to overwrite. In my current
project the implementation on the proof of concept wouldn't work.
About which one runs the server... that's good question. Surely having
the slave running the server simplifies connecting to it (since most
likely you know the IP), but what about security? We could password
protect it somehow with a password read at runtime.
And I agree, abstract the server and being able to run it on both
master and server sounds like a good idea.
J
Juan Delgado
Oct 16, 2011, 12:07:12 PM10/16/11
to DConsole
Hi there,
I've been looking into pushing the master/slave console further, but
I'm struggling to come up with a clean implementation.
While I do understand the value of both methods (slave implementing
the server a-la telnet vs slave connecting to a given master), trying
to put both together in one single implementation makes things messy.
So either we have one implementation for each method, sharing as much
code as possible, or we go for one method only. I'm leaning towards
implementing the slave connecting to master version first, since
that's the one I would be using myself, but I thought about asking
first.
Has anybody gone any further?
Cheers!
Juan
--
Juan Delgado - Zárate
http://zarate.tv
http://blog.zarate.tv
Reply all
Reply to author
Forward
0 new messages