Socket freezes based on client connectivity...

Question

Hello,
We've been suffering through a problem in our game for several months, and I have yet to identify why the problem occurs. I've written a small program that duplicates the problem, perhaps someone here will be familiar with what's causing it, and be able to help.
The problem occurs when one of the connected clients loses internet connectivity (usually this is due to people with microwave style or dial-up connections to the internet that lose their signal). The data continues to be transmitted to their socket, and appears to queue up locally to a certain point. After the queue reaches a certain size, the server thread blocks, and will not continue past the point of sending that data to the 'locked' socket. So a single player's locked connection ends up freezing everyone else's screen updates, as well.
We've been able to emulate the problem by using the WinXP telnet client and bringing up the right-click menu. (This appears to make the telnet client stop accepting data from the server, so the data queues up and the server locks.)
The three source code files to duplicate this problem can be downloaded in an archive from here: http://www.aros.net/~rumour/TestServer.zip
I will also paste the code in-line the post, following the remainder of my message.
The main method is in TestServer, which will bind to port 1234 of the machine on which it's run. To duplicate the problem, use telnet to make a connection to the server. (The server constantly streams data, so that it won't take long for the queue to fill, and the problem to manifest itself.) Launch a second telnet window which you can freeze (as I mentioned, by right-clicking on a WinXP telnet window [so right-click menu, Mark, Copy, Paste, etc., is visible], and then leaving that menu up, seems to be a great way to duplicate the problem) and connect it to the server also. Freeze the 2nd connection, and observe the 1st. After a short period of time, the 1st connection will also stop updating.
My hope with SocketChannels was that it might bypass the problem, however, it occurs with this implementation, as well. (Was trying to force a non-blocking socket solution, in case that was the problem.)
Does anyone have any ideas or experience with a similar problem? We would be most appreciative of any solutions, suggestions, alternatives, or insight into what's going on. And if you'd enjoy seeing the game, please visit http://mtrek.game-host.org - it is a telnet based, real-time space combat game, based on the classic MTrek.
Thank you for your time,
J.
TestServer.java
import java.net.BindException;
import java.net.InetSocketAddress;
import java.net.ServerSocket;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
public class TestServer {
  public static void main(String[] args) {
    TestConnections tc = new TestConnections();
    tc.start();
    // establish server socket, and bind to a port
    try {
      ServerSocketChannel ssc = ServerSocketChannel.open();
      ServerSocket sc = ssc.socket();
      sc.bind( new InetSocketAddress( 1234 ));
      SocketChannel client;
      do {
        client = ssc.accept();
        if (client != null) {
          System.out.println( "Socket connection accepted: " + client.toString() );
          tc.addClient( client );
      } while( true );
    } catch( BindException be) {
      System.out.println("Error binding to port.");
    } catch( java.io.IOException ioe) {
      ioe.printStackTrace();
TestConnections.java
import java.util.Vector;
import java.nio.channels.SocketChannel;
public class TestConnections extends Thread {
  private Vector clients;
  private int dataLine;
  public TestConnections() {
    clients = new Vector();
    dataLine = 0;
  public void addClient( SocketChannel client ) {
    TestClient tc = new TestClient( client, this );
    clients.addElement( tc );
    tc.start();
  public void removeClient( TestClient client ) {
    clients.remove( client );
  public String getDataLine() {
    // rotate through printable characters, 32-126
    StringBuffer sb = new StringBuffer();
    for (int x = 0; x < 72; x++) {
      sb.append( (char) (((x + dataLine) % 95) + 32) );
    sb.append("\r\n");
    dataLine++;
    return sb.toString();
  public void run() {
    try {
      do {
        Thread.sleep( 10 );
        // loop through all clients, and transmit data
        for (int x = 0; x < clients.size(); x++) {
          TestClient curClient = (TestClient) clients.elementAt(x);
          String transmitString = getDataLine();
          curClient.sendData( transmitString );
      } while( true );
    } catch( InterruptedException ie ) {
      ie.printStackTrace();
TestClient.java
import java.nio.ByteBuffer;
import java.nio.channels.SocketChannel;
public class TestClient extends Thread {
  private SocketChannel client;
  private TestConnections connections;
  public TestClient( SocketChannel clientSocket, TestConnections connectGroup ) {
    client = clientSocket; 
    connections = connectGroup;
  public void sendData( String data ) {
    try {
      client.write( ByteBuffer.wrap( data.getBytes() ));
    } catch( java.io.IOException ioe ) {
      ioe.printStackTrace();
      connections.removeClient( this );
  public void run() {
    try {
      do {
        Thread.sleep(10);
      } while( true );
    } catch( InterruptedException ie ) {
      ie.printStackTrace();
}

Answer 1

I've come to a workaround that, while I'm not particularly happy with it, it works. Before the actual transmission of the data, I instantiate a Timer object that will kill the socket unless the send succeeds within a certain amount of time. The reason I'm not particularly happy with this, is that the transmit method is called very frequently. That's a lot of extraneous Threads getting spawned and killed. I'd prefer to solve this another way, but this is working for the time being.
For instance, in my sample code, I altered the client sendData method to look like:
public void sendData( String data ) {
    try {
      Timer timeToKill = new Timer();
      timeToKill.schedule( new TestTimer( this ), 5000);
      client.write( ByteBuffer.wrap( data.getBytes() ));  // you have 5 seconds to comply
      timeToKill.cancel();
    } catch( java.io.IOException ioe ) {
      ioe.printStackTrace();
      connections.removeClient( this );
  }And added a new class, TestTimer.java:
import java.util.TimerTask;
public class TestTimer extends TimerTask {
  TestClient clientToPotentiallyDestroy;
  public TestTimer( TestClient t ) {
    clientToPotentiallyDestroy = t;
  public void run() {
    clientToPotentiallyDestroy.kill();
    try {
      clientToPotentiallyDestroy.client.socket().close();
    } catch( java.io.IOException ioe ) {
      ioe.printStackTrace();
}Before each write call [ client.write(...) ] in the sendData method, a new Timer thread is created with an arbitrary wait period (I actually lowered it to 1 second in the game itself, since it should immediately be able to dump the data to the socket unless it's already been queuing up for quite some time) if the write succeeds within that time, the Timer gets cancelled, and program continues. If the write does not succeed within the specified time, the TestTimer object gets called from the Timer, and the 'offending' socket gets closed by force. This kills the client Thread which ends up blocking the program execution because of the size of the send queue.
Hopefully, this may help someone else encountering a similar problem, although I'm still hoping for a more elegant solution.
--J.