ncurses & telnet protocol -


i'm working on program exports text user interface based on ncurses via telnet. works when use hard coded values:

 fd = accept(sfd, null, 0); // tcp socket client   file *fh = fdopen(fd, "rw");   screen *scr = newterm("vt100", fh, fh);  setterm(scr);  resizeterm(25, 80);   // ...regular ncurses code... 

in ncurses use getch() retrieve key-presses. automatically convert special characters cursor-key-up/down/etc (esc [ , such) constants key_up.

telnet uses special byte-codes communicate parameters terminal window size, terminal type etc telnet-client , vice versa.

if want rid of these hard coded values, need send telnet codes need receive responses.

my question is: these telnet codes interfere ncurses? able use getch() or getch misinterpret ncurses codes special characters?

the place start rfcs: rfc 854 - telnet protocol specification says character 255 (0xff, iac) reserved communication between client , server.

there's disconnect between rfc (theory) , practice (implementations). rfc written obvious intention of supporting simple teletype-replacements (i.e., no cursor addressing, no escape sequences @ all). standpoint of rfc, once start considering terminals (most of available ones when rfc published in 1983 did support cursor addressing), there's not except careful not send (unescaped) character 255.

rfc 854 updated (not obsoleted) rfc 5198 - unicode format network interchange in 2008. rfc 854, assumes uses glass teletype, recommending backspace character not used cause behavior on different systems may differ. 1 useful comment in rfc states character 255 not part of valid utf-8 string.

if not using utf-8, iso-8859-x encodings may send 255. valid printable character. ncurses not send character unless data happens include it, ncurses has no special provision escaping character.

ncurses assumes communication path 8-bit clean. rfc 856 - telnet binary transmission addresses part of this, leaving achilles heel of iac untouched:

with binary transmission option in effect, receiver should interpret characters received transmitter not preceded iac 8 bit binary data, exception of iac followed iac stands 8 bit binary data decimal value 255. iac followed effective telnet command (plus additional characters required complete command) still command binary transmission option in effect. iac followed character not defined telnet command has same meaning iac followed nop, although iac followed undefined command should not sent in mode.

you may of course run implementation 8-bit clean, not comply rfc.


Comments

Popular posts from this blog

python - Selenium remoteWebDriver (& SauceLabs) Firefox moseMoveTo action exception -

html - How to custom Bootstrap grid height? -

transpose - Maple isnt executing function but prints function term -