This is indeed a charming idea.
Please consider a few things, most important first.
- Any telnet daemon inside the IOC will close the connection when the IOC goes down (reboots or crashes). The client will have to detect this, and act accordingly, e.g., go into a loop trying to reconnect.
This means that the client will not be able to see early boot messages that are printed before the daemon is up and the client connects. Please remember that back in vxWorks times, this was the main reason to not use the remote shell connection, but add terminal servers connected to the serial console.
The procServ daemon survives and keeps the clients connected, which will not miss a single byte of a new boot sequence. - This will obviously solve the remote connection part, not the restart.
Depending on the target platform, the restart will have to be done and configured very differently. This is lowering the portability of solutions.
- For TCP, the IOC should implement the telnet protocol. (How else deal with clients from systems with other end-of-line behavior?)
procServ is using libtelnet, or compiling the libtelnet sources on platforms that don't offer it packaged.- Consider supporting Linux domain sockets. These are named (no need to manage TCP-port-to-IOC assignments) and don't require telnet protocol.
- What about Windows?
cygwin would offer a full Posix interface, but we just dropped it as a target platform.
Just my 2cts...
~Ralph
