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

This is a discussion on Providing multiple command line (telnet) interfaces to control an application - Networking ; 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 ...

+ Reply to Thread
Results 1 to 2 of 2

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

  1. 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
    (
    and others)
    - Virtual consoles (from
    and )
    - Pseudo terminals (from
    )
    - TTY drivers (from Chapter 18 of "Linux Device Drivers")
    - getty (from <http://www.busybox.net/downloads/
    BusyBox.html#item_getty>)
    - inetd (from )

    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


  2. Re: Providing multiple command line (telnet) interfaces to control an application

    On a sunny day (Tue, 26 Jun 2007 13:00:14 -0700) it happened Steve Strobel
    wrote in
    <1182888014.480193.190430@n60g2000hse.googlegroups. 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.

+ Reply to Thread