No announcement yet.

Avoiding Telnet Collisions

  • Filter
  • Time
  • Show
Clear All
new posts

  • Avoiding Telnet Collisions

    My program is roughly based off the commandline.c demo. I added ?extensions? to the standard CLI. The host (PC) side is sending commands to both the extensions and ?standard? functions via Telnet. A task is running to deal with an external device which sometimes sends back result messages to the PC. In the meantime, another CLI command might be transmitting data and the results get inter-mixed and the Telnet session will unexpectedly exit. I need a way to query the Telnet (or socket) session to see if it busy before I write to it.

  • #2
    Asynchronous CLI responses

    There is presently no facility to allow an independent task to safely write a response to a CLI session.

    Here is one suggestion as to organize it:

    When your "extension" CLI routine gets control, have it set things up as it already does. Add a global variable to allow the independent task to communicate with your routine. Your routine could loop, waiting for the response. In the loop you would want to Yield so you allow other tasks to run. In the loop you might also want to test for a character from the user to "escape". When the independent task has something to say, it could allocate memory for the information, then place the pointer in the global. Your CLI routine would find and use the information, then Free the pointer and NULL the global. Now since your CLI routine is writing all of its responses, there are no collisions.


    • #3
      Asynchronous CLI responses

      I have tried what you suggested before... Looping in the CLI thread and waiting for a response which I acquired in a different thread and protected with a Mutex. Several problems with that though. I've found that looping in a CLI routine will block any subsequent CLI command, and I am delaying the thread to allow others to run. Also, some commands have no responses so there is no need to loop and wait for one.
      I think what I might do instead (if you guys can't explain to me the contents of command_io struct or some way to check status on the telnet session) is create a thread on the PC that checks status intermittently when other commands aren't being sent... That or just use UDP to send back status.


      • #4
        Avoiding CLI stream collisions

        There presently is no semaphore or state variable in the firmware that would block or indicate that a response is being sent for a command. What the command_io struct does contain is for a wholly different purpose and would definitely not help with what you seek.