Providing multiple command line (telnet) interfaces to control an application

I am porting an application to uClinux which I want to be able to
control via telnet. Actually, I want to allow multiple simultaneous
telnet sessions that all control the same instance of the program (or
at
least the same "core" of the program). I can run multiple instances
of
the program, but then I have to figure out which one should control
the
hardware. I am interested in any suggestions about how to do this.

Background: The original (non uClinux) version supported multiple
command line interfaces. For the sake of argument, think of it as
having a quad-uart, with each uart connected to a separate serial
terminal. A single executable serviced all of the terminals, polling
each in turn, processing commands, updating values in memory, and
controlling hardware. Because everything was done from a single
executable, a command could be entered from any one of the terminals
and
it would update the same values in memory and control the same
hardware.

My initial uClinux port runs fine using the serial port as a command
line interface (there is only one serial port in this version of the
hardware). I can also telnet to uClinux (getting the msh shell from
BusyBox) and run it from there. I can create multiple telnet sessions
and run a separate instance of the program from each. That is almost
what I am looking for, except that I have a completely separate
instance
of the executable running for the serial port and each of the telnet
sessions, and no good way to keep a common set of values in memory nor
to determine which instance of the program should control the
hardware.

It seems to me that I need to break my application into at least two
executables, a "core" that would control the hardware, and a separate
program that would communicate with the core and provide a command
line
interface (a custom shell). This would be very similar in concept to
the Linux kernel and having multiple consoles running Bash. I am
struggling to figure out the best way to make the core and custom
shell
communicate. I would be grateful for any suggestions.

-----------------

I have considered a variety of options for making the core and custom
shell communicate, but I don't understand the "Unix Way" of doing
things
well enough to know which to pursue. The following are some of my
thoughts; they may or may not make sense.

Because the original application already knows how to service multiple
command line interfaces, it seems like it would be straightforward to
make the "core" provide four virtual serial ports (to correspond with
the original quad uart) and make each instance of the custom shell
connect to one of them, print any output and return any keyboard
input.
The virtual serial port could maybe be a socket or something in the /
dev
directory (I don't understand how they work yet). The custom shell
could try to connect with each of the virtual serial ports in turn
until
it found one that wasn't already in use. Obviously the number of
custom
shells that could be used at one time would be limited by the number
of
virtual serial ports.

I have been reading online about the following, but I haven't quite
been
able to figure out how they apply to my situation:
- Unix shells (changing the shell with chsh, etc)
- Consoles
(<http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO-7.html#ss7.1>
and others)
- Virtual consoles (from <http://www.bellevuelinux.org/console.html>
and <http://www.bellevuelinux.org/console.html>)
- Pseudo terminals (from
<http://en.wikipedia.org/wiki/Pseudo_terminal>)
- TTY drivers (from Chapter 18 of "Linux Device Drivers")
- getty (from <http://www.busybox.net/downloads/
BusyBox.html#item_getty>)
- inetd (from <http://en.wikipedia.org/wiki/Inetd>)

It seems that virtual consoles are close to what I want ("A virtual
console...is a conceptual combination of the keyboard and the display
for a user interface...represented by device special files /dev/tty1,
/dev/tty2 etc."), but this part doesn't apply, "...accessed from the
same physical console (i.e., same keyboard and screen)." I don't
think
I need to use multiple virtual consoles provided by the Linux kernel
as
they would just let me run multiple instances of my program; I think
I
need to implement similar "device special files" that my custom shell
could connect with. Am I even on the right track? Is there a better
way?

Thanks for any pointers/suggestions you can give me.

Steve

On a sunny day (Tue, 26 Jun 2007 13:00:14 -0700) it happened Steve Strobel
<(E-Mail Removed)> wrote in
<(E-Mail Removed) .com>:

>I am porting an application to uClinux which I want to be able to
>control via telnet.

>My initial uClinux port runs fine using the serial port as a command
>line interface (there is only one serial port in this version of the
>hardware). I can also telnet to uClinux (getting the msh shell from
>BusyBox) and run it from there. I can create multiple telnet sessions
>and run a separate instance of the program from each. That is almost
>what I am looking for, except that I have a completely separate
>instance
>of the executable running for the serial port and each of the telnet
>sessions, and no good way to keep a common set of values in memory nor
>to determine which instance of the program should control the
>hardware.

It (I am running busybox on embedded with serial and telnet myself) does
not make a lot of sense to 'control the same hardware' from different points.

To accept multiple connections and pass on control from these you need
to write a server like application.

For example I have written a camera server that sends data to X number of clients,
and each of those clients _can_ change some parameters, say shutter time or
somethin, but you will quickly find that there would be a conflict when
different users want to do different things.

For a very simple example for server client see libc.info ( usr/info/libc.** )
Server can be just a few lines.