Monday, May 28, 2012

Android Sockets

So I thought that socket programming was going to be difficult for the Android platform. Turns out, Android uses the standard java.net.Socket API. So your basic Java socket program also applies to Android. Now if you are a Java programmer, then you'll know that there are two different ways of using sockets in the standard library provided by the JRE. There are a ton of other socket APIs out there, but they are third party. The JRE only comes with two APIs for sockets.

  1. The java.net.Socket API and related family
  2. The NIO way of doing it.

The old socket way was invented to mimic Unix sockets. The NIO way is much more complex and I've only done a little bit of programming in the NIO way, so I'm relived that Android uses the old socket API. Enough beating around the bush, let me show you a very basic example of a client using java.net.Socket.


package lan.testing.SimpleClient;

import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.IOException;
import java.net.Socket;
import java.net.UnknownHostException;

import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

public class SimpleClient extends Activity {

  private EditText messageSend;
  private TextView messageRecv;

  /**Setup all your GUI stuff */
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);
  
    messageSend = (EditText)findViewById(R.id.messagesend);
    messageRecv = (TextView)findViewById(R.id.messagerecv);
    Button buttonSend = (Button)findViewById(R.id.send);
    buttonSend.setOnClickListener(buttonSendOnClickListener);
  }

  Button.OnClickListener buttonSendOnClickListener = new Button.OnClickListener(){

    @Override
    public void onClick(View arg0) {
      Socket socket = null;
      DataOutputStream dataOutputStream = null;
      DataInputStream dataInputStream = null;

      try {
 socket = new Socket("192.168.99.1", 8888);
 dataOutputStream = new DataOutputStream(socket.getOutputStream());
 dataInputStream = new DataInputStream(socket.getInputStream());
 dataOutputStream.writeUTF(messageSend.getText().toString());
 messageRecv.setText(dataInputStream.readUTF());
      } 
      catch (UnknownHostException e) {
 e.printStackTrace();
      }
      catch (IOException e) {
 e.printStackTrace();
      }
      finally{
 if (socket != null){
   try {
     socket.close();
   }
   catch (IOException e) {
     e.printStackTrace();
   }
 }
  
 if (dataOutputStream != null){
   try {
     dataOutputStream.close();
   } 
   catch (IOException e) {
     e.printStackTrace();
   }
 }

 if (dataInputStream != null){
   try {
     dataInputStream.close();
   }
   catch (IOException e) {
     e.printStackTrace();
   }
 }
      }
    }
  };
}

That there is a basic client application that will send a message to 192.168.99.1 on port 8888 and then receive a reply back. The message to send is in a text edit box and the message received is placed in a text view widget. If you've ever taken a college course on Java Sockets then Android Sockets will make you feel right at home. Very little if anything is different between the two.

Next go round, I will create a socket and hold a telnet negotiation conversation with the server. Sorry if post seem to be stretched out. Company has me working on a tool for working with our vast store of XML documents, fun on the bun. Also, I'm still reading the RFC on the TN5250 stream format.

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.

Sunday, May 20, 2012

Interesting things about Telnet. So the start of any foray into Telnet begins with the IETF RFC 854 (http://www.ietf.org/rfc/rfc854.txt). There you can get the gist of how the protocol works. Basically it covers what is know as the Network Virtual Terminal (NVT). This is basically the version of telnet that has zero additional features turned on. In other words, all optional features are turned off for NVT. That's not to say that NVT has no features, it just that all features that are in NVT are required to technically have a telnet client. A telnet client implements at least every feature that NVT supports. Telnet clients also may negotiate what features will or will not be used by an exchange of DO, DON'T, WILL, WON'T. All commands start with the IAC code (Interpret As Command). This is octal /377 or hex 0xFF. For example, most modern clients use full-duplex communication now-a-days. So one of the first things exchanged by telnet clients is IAC WILL SUPPRESS-GO-AHEAD or in hex 0xFF 0xF1 0x03, octal /377 /361 /003 (because for some reason octal is the what everything seems to be expressed for telnet.) Anyway, that whole SUPPRESS-GO-AHEAD function is not defined by IETF RFC 854, it is defined by RFC 858! Now we reach the problem I'm currently having with telnet. Going through and trying to find all of these dang RFCs that define telnet so that I have a modern client... Of course, once I have then all in hand, I'll still need to figure out which ones are relevant to tn5250... At the same time, I'm brushing up on Android socket programming. Believe it or not, the SDK documentation is pretty good. I'll still do a couple of dummy echo server/client programs to get a feel for socket programming in Android. The nice thing is that I have two tablets with Ice Cream Sandwich on them, so I'll be able to play with socket programming on them. One the client and one the server. Also, I'm not going to be targeting anything below 4.0. If the client runs on Android pre-ICS, then it is by pure dumb luck. Finally, I'm going to have to find a better code syntax highlighter for this blog before I start putting code up here. Cheers!

Whoa! I'm not dead I swear!

I've been mostly silent on Blogger.  I've just not had enough time with all of the projects that get tossed at me at work...  Well since I was last posting to this site I have now come across a new pet project of mine.  TELNET!  Now I know, why would anyone want to study a protocol that has been replaced by better protocols?  The answer is to develop a tn5250 terminal for Android that is awesome!  I currently, don't know of any tn5250 terminal for Android so it would be cool to have one up on the market.  Obviously, it will be free of charge.  I just cannot imagine charging people for something that I hope to be really useful!

Right now I'm posting this to my blogger account via an Android app.  So as you can see, I'm really liking the Android platform, but I think that there is a huge lacking of the open source movement on Android.  Some apps on the market will have links to the source code, but not a lot.  So I'm really committed to getting this tn5250 emulator up on the market and finding somewhere to host the source code.

Okay so now, I bet you are thinking.  How hard can a telnet client be?  If you are thinking that it is just a text based protocol, then you'd be dead wrong.  There are indeed special control characters in the telnet protocol and there is even a binary mode!  Basic telnet doesn't use any of these, but tn5250 takes advantage of everything plus some that telnet has to offer.  So this should be interesting.

Expect over the coming months, for me to paste my musings about telnet here.

PS:  Since I'll be working in Java, I'll look at making a nice little tn5250 buffer reader targeted at people who want to screen scrap tn5250 streams.  No promise because I really want to focus on the tn5250 emulator for Android.

Cheers!