This is not really jME related but as i know no specific networking forum and believe that enough capable people are around here as well, i'll just post this here 
At university we learned to spawn a seperate listening thread on the server for every client connected to listen for its messages.
When I started my networking, my brother argued that it would be way too much needless overhead to create thousands of threads if you have thousands of clients connected at the same time (like it is the case on game servers) and that it would be better to create a list of clients that is repeatedly checked by only one thread which adds a received message to a message queue that is then processed by another thread.
You would save the Thread switching and memory overhead and cycling through the list wouln't be much effort.
I implemented it this way and it works for my test cases.
But 10 minutes ago, i discovered that the way i did it, it would be indeed pretty inefficient when used for real applications.
Because while checking client connection #1, the listening thread blocks until he receives a message from client #1, thus not coming to client #2 until then.
(And so on for all other client connections in the list.)
So I would need to check for a waiting message on that connection instead of blocking and waiting for one.
I searched, but (Object)InputStream does not provide any methode to poll if there is a new message, but only the various read methodes that block the listening thread.
So what i ask myself currently is:
Is my brother's methode not applicable in Java because input stream only provides the blocking read methodes?
Or can you somehow check for new messages in queue before calling a read methode?
Or is it no big deal anyway to have thousands of tiny listening threads that block most of the time?
Then his whole idea wouldn't be necessary, of course.
Thx for answers
Hi,
I think you'll need to use NIO for non blocking IO. Using non blocking sockets is the only way to have a scaleable server that can handle thousands of connections.
- Chris
Many threads is typically not that bad. I believe most Servlet Containers still go that route. However, NIO has much better performance scalability.
WARNING: Shameless advertising follows:
I would recommend NIO but Java’s NIO features can be ultra complicated (as it’s taken me time to figure out) and is why I wrote JGN. JGN provides complete NIO with support for multithreading but can be run entirely in the OpenGL thread.
http://javagamenetworking.dev.java.net
http://forum.captiveimagination.com
Thx both of you.
Problem with the "completely in the openGL thread" is, that my server has no openGL / jME thread.
It's just a server so it needs no graphic (alhtough it has some jME geometry for collision checking).
As my work is only for a thesis (so far) it is highly doubtful that it will ever have to handle thousands of connections in the first place.
So not to waste too much time, i'll just do it as our prof said and spawn those threads.
But i'm another step closer to looking into your JGN if it should become necessary in the future
(meaning your advertising worked 
)
I guarantee it will be easier with JGN. As far as the OpenGL thread though, I agree. It's generally not a good way to go anyway, but JGN has a method JGN.createThread(…) that can take one (or several) MessageServers and/or other "Updatable" implementations and create a thread for you that can then simply be started.
If you're at the beginning of your project I would highly recommend NIO as you'll encounter fewer problems in the long-run and singificantly better performance, but like I said previously, you can probably just as well get away with multiple blocking threads.
I've been going through the examples for JGN over the last few weeks. It it not required to be used inside of opengl or jME, actually it appears to be a completly standalone deal. It has the added 'feature' to be integrated very easily into jME.
So I think you should really check it out, pretty neat stuff if you ask me!
The examples aren't written around jME, so you can really see what you get.
@darkfrog: Correct me if I'm wrong.
That's correct. I have extending APIs I've written to add explicit ties to other projects like jME. It's an incredibly simple API.