Skip to main content
gamedev.net
🔒 Locked

[java] 50 threads

Started by fenghus Nov 16, 2001 at 6:45 PM 4 replies 1.2k views
Original Post
fenghus
fenghus
I''m making a game with up to 40-50 people connected to a server at one time - as far as i can tell i need one thread per client for reading data from a tcp socket. Will 50 concurrent threads suck my server dry performancewise? If so, is there a way to use non-blocking socket operations? java.nio? tia, --Michael
superpig
superpig
Can''t you assign one thread to, say, 5 sockets, and just have it loop through them? Performance hit client-wise, but only small.

Superpig
- saving pigs from untimely fates
- sleeps in a ham-mock at www.thebinaryrefinery.cjb.net
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
fenghus
fenghus

After reading up on java.nio.* i believe the alternative to having 50 threads each reading on blocking sockets is to get channels for each of the 50 sockets and set them as non-blocking. Then in one single thread loop thru all sockets and read from wherever there are data available...

I this reasoning sane? If so, which alternative will provide me with the best performance?

--Michael

ps. sorry for posting without rtfm first ds.
mjacobsca
mjacobsca
I don''t think 50 threads will suck your server dry as long as the threads are very minimal and stick ONLY to reading sockets and notifying the main system when an important event has to take place. The communication threads should be as minimal as possible so they can keep reading data from the input stream.

The bigger issue, I think, is how your app can handle 50 players at once from a bandwidth standpoint. If you are programming a game that will be sending a lot of data, then you''ll have many areas that will require optimization.

c_wraith
c_wraith
50 threads isn''t a problem. 500 might be. 5000 almost certainly would be. The point where performance collapses is OS and hardware dependent, but at some point there are just too many threads for scheduling to work well.

The alternative, in java.nio, is the Selector stuff. The documentation on it isn''t too clear unless you already understand how it should work from things like select() in various unix C libraries. It is the key to using non-blocking IO effectively without high CPU utilization, so it should be learned.
fenghus
fenghus
I think i''m going to have a go at it with the selector stuff, to avoid the problems that can arise when 50 threads are reading and writing to the same data.

The game is a mmorpg-like one, without the "massive". I will be using both UDP and TCP for different stuff in the game, but bandwidth will be a tough issue indeed.

--Michael

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.