Monday, May 21, 2012

Foray into a telnet conversation

So here is a little bit of a recorded conversation that someone from the Internet had with a telnet server:

server:  IAC DO TERMINAL_TYPE
client:  IAC WILL TERMINAL_TYPE

server:  IAC DO OPT_END_OF_RECORD
client:  IAC WILL OPT_END_OF_RECORD

server:  IAC DO TRANSMIT_BINARY
client:  IAC WILL TRANSMIT_BINARY

server:  IAC DO TIMING_MARK
client:  IAC WONT TIMING_MARK

server:  IAC DO NEW_ENVIRONMENT
client:  IAC WILL NEW_ENVIRONMENT

server:  IAC SB TERMINAL_TYPE
client:  IAC SB TERMINAL_TYPE QUAL_IS IBM-3179-2 IAC SE

Or in hexadecimal:

server:  FF FD 18
client:  FF FB 18

sever:  FF FD 19
client:  FF FB 19

server:  FF FD 00
client:  FF FB 00

server:  FF FD 06
client:  FF FC 06

server:  FF FD 27
client:  FF FB 27

server:  FF FA 18
client:  FF FA 18 00 49 42 4D 2D 33 31 37 39 2D 32 FF F0

As you can see there isn't really a rhyme or reason to when the questions will be asked in a conversation. The server asked if the user would negotiate a terminal type first and then started that process after asking a couple of other questions. Also, it asked if the user would use timing marks (RFC 860: http://tools.ietf.org/html/rfc860) and the user said that they would not do so. Saying that you won't do something when the server asks you to, could end the connection. However, as you can see here, the server takes note of the WONT TIMING_MARK and apparently can deal with this refusal since the conversation continues. Not every server will be as forgiving.

This brings up what I'll need to watch for when building a tn5250 client during the start up of the socket. Basically, I'll need to watch for certain questions and respond by building answers. The simplest way of do this would be a switch statement. I have heard from some forums, that IBM iSeries systems seem to toss out extra IAC DO for no reasons. Now the thing is this, it will toss out IAC DO, but there won't be anything that follows up, so the stream could be IAC DO IAC DO TERMINAL_TYPE. The thing will be to check to see if this extra IAC DO exists in the stream and dump it.

With that said, I think the next step is to stop look at the telnet stream for a second and begin working on some example Android sockets. Next post will be a basic Android socket program. I am going to try to build a Java and Android base library (aka, a library that will work both in Java and Android) as the final result, but for now let's focus just on Android before we go back and try to make it platform agnostic.

No comments: