01-22-2010

Today I'm going to simplify the proxy code to work only with telnet and ssh.  Those protocols are single server only and should help to verify the logic.  Perhaps later, I'll put in an HTTP "personality".  Tried taking out the "sleep" code and testing with ssh and telnet.  Telnet almost works but nothing every cleans up.  It appears that, for some reason beyond my current understanding, we need to do the "sleep" trick.  I'll try that with telnet and see how that fares.  The sleep model doesn't seem to work well because if the timing is wrong, you end up closing a connection before you want to.  If I don't use the sleep model and don't wait on the futures, things almost work. If I fire up top in the telnet session, I can't seem to get out.  If I exit from the telnet session, I see the server side thread clean up but the client side thread is still waiting on the input.  I think I need to each thread to notify each other if one side of the connection is broken.  Just learned something.  You can't rely on interrupt() to unblock a thread waiting on i/o.  It is platform specific.  The reliable way is to close the i/o stream that the thread is waiting on.  This helped me to improved the proxy.  When I create the paired stream handling threads, I set up a references to each other so that that when one stream closes, such as when exiting a telnet session, the other stream is closed which breaks the loop.  Seems to be working.  Yay!

The next step is decide what do with the bytes as they stream by?  Do we save 'em to disk for later examination?  Do we show them in real-time like tcpmon? Both?  Can we do this without impacting performance of the proxied streams?

Each "session" now has four objects, each running on its own thread.  One to open the connection to the server and setup the remaining objects.  One to listen on a blocking queue for data to write to a file.  One to shuttle data from client-to-server and one to shuttle data from server-to-client.  It seems to work but I need to settle on the format of the output file.  Raw data with no time stamping or direction might not be useful but putting that stuff in forces us to create a text file, right?