Author Topic: Telnet - Large menus and large series of fnDebugMsg after commands get cut off  (Read 9616 times)

Offline thamanjd

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
in Telnet ive got a problem with large multiline help menus getting cut off. Also if i try to show a table after a command of 24 lines by around 35 chars per line, it gets cut off towards the end of line 11.

If i reduce the number of chars per line it will display more lines before it gets cut off.

after it gets cut off i can still enter the command again but then it gets cut off at the same point.

Has this go to do with a timer or something that i can change?

JD

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Hi John

This has to do with the size of the TELNET TCP Tx buffer (the size is defined in app_hw_xxx.h in the buffered TCP section).

See the following for more details on buffered TCP mode of operation as used by TELNET:
http://www.utasker.com/forum/index.php?topic=25.msg101#msg101

Sending large amounts of data is a bit of a challenge when only small amounts of RAM are available since TCP, being a reliable protocol, must always be able to regenerate lost data packets. This means that there must be a backup of the data kept until it is sure that it has been delivered. To allow larger menus to be displayed, it is simple to increase the size of the buffer (#define TCP_BUFFER 4096 for example) to allow up to this size of waiting data to be added to the buffer.

If the buffer gets overrun, the following data is lost (the bytes with no space are dropped, as you are seeing).

With limited memory, simply increasing the buffer space is often not an alternative so a different solution is required. The demo project does in fact include an example of how this can work. The demo project intentionally uses quite a small TCP buffer size with the TELNET interface and a menu rather larger than it. If you look at the menu generation in debug.c you will see that the space available in the buffer is first checked as each line of the menu is generated. If there is enough space, the data is simply copied. If there is not enough space, the menu generation is interrupted and the task waits for the TX_FREE event (informing of buffer space availability) before continuing.

Of course this makes the code slightly more complicated (but not really difficult) but allows efficent TELNET operation (using windowing on transmission for high speed) but requiring only quite a small amount of memory.

Good luck

Regards

Mark


Note: the TCP buffer space is taken from the heap. Ensure that the heap size allocation is adequate to enable any increased buffer size.
« Last Edit: October 08, 2007, 03:43:03 PM by mark »

Offline thamanjd

  • Jr. Member
  • **
  • Posts: 57
    • View Profile
ok. on the ne64 i don't think i have a lot of lattitude with the buffer space. The best i could do was 482 bytes. Ive cut down the format of the table i was showing using a series of fnDebugMsg and it just fits.

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Hi John

Yes, the NE64 is rather tight in terms of internal SRAM.

You can send larger menus if you use the TX_FREE event to allow the menu to be build up as a series of blocks. The uTasker NE64 demo sets the TCP buffer size to 450 bytes and the LAN configuration menu is built up as a series of 3 distinct blocks (the buffer fills three times during the process and in each case the menu generation has to be temporarily interrupted until space is available again).

Even if the TCP buffer is reduced to 100 bytes it will still be able to display the menu quite rapidly but the internal working actually needs the LAN configuration menu to be built up as a sequence of 20 blocks! Obviously not the most efficient TELNET operation possible (using 100 byte TCP frame payloads) but it shows that it is possible to do things often restricted to the the realms of larger systems even with very limited RAM.

Regards

Mark