java.nio as opposed to java.net - basic difference in program logic?

[Chris Berg]

My client/server application is using plain sockets, in the
traditional way:

ServerSocket ss=new ServerSocket(port);
while (true){
new Handler(ss.accept());
}

......

class Handler{

Socket s;

public Handler(Socket s){
this.s=s;
new Thread(this).start();
}

public void run(){
while(true){
read a command from s's inputstream;
interpret it;
write a reply to s's outputstream;
if (user logs off) break;
}
}

}

Of course, there is more to it - setting the socket timeout, etc., but
I'm sure you get the picture.

I worry about how my server will react to many simultaneous clients,
each with not too much activity, but there may be a lot of concurrent
threads (thousands), consuming many system ressources.

Now, I'f noticed the new java.nio classes that seem to handle multiple
clients in a more efficient way. Only, I'm concerned that I will have
to completely re-write the program logic to make it fit into the
scheme. As everything runs on the same thread, I must program it in a
more event-handler-oriented manner, where I need to save a state
vector for every client, which would roughly correspond to the current
program location of each of the old threads. Or is there maybe a
smarter way to do that?

Also, some of the command-handling code can be blocking (ie.
Thread.sleep() or disk file I/O). This means that I'll have to leave
the handler and go back to the Selector and service incoming commands
before having finished current commands. What a mess! It must end up
with some ugly code!??

Chris

 

[Sudsy]

My client/server application is using plain sockets, in the
traditional way:

Also, some of the command-handling code can be blocking (ie.
Thread.sleep() or disk file I/O). This means that I'll have to leave
the handler and go back to the Selector and service incoming commands
before having finished current commands. What a mess! It must end up
with some ugly code!??

Chris

The java.nio classes permit me to write code similar to a UNIX
daemon which uses select(). The Jave implementation is actually
a bit nicer since I don't have to do a fork()/exec() to start a
subprocess; I can just do new Thread( Runnable ).start(). Less
overhead.
It doesn't have to be messy if you clearly understand your goals.
Supposedly you'd want to handle the "pedestrian" requests in the
main thread and only create a new thread for those operations
which could take some time to complete.
Think of an Apache/Tomcat installation. When configured in the
"standard" way, Apache takes care of serving requests for static
content and only the active content requests get forwarded to
Tomcat.
If certain requests could block on disk or network I/O then they
deserve their own thread. If this traffic represents only 10% of
the total then you'll be ahead of the game. Just map out your
architecture carefully.