-1

Initially I was thinking to use sockets where a player

sends a request to the server, the server processes the request, and sends a reply. Or the player may need to send a query for game-state changes every so often.

Is this the worst idea?

Second question, pertains to the server side code. Currently each incoming connection spawns a new thread to run it's task, mainly reading some files off a hard drive and sending strings back to the android device that requested it in response.

But I wonder about scalability. For instance suppose a million players each open a socket thread every minute, which lasts for 10 seconds. At any given time there could be like 20,000 concurrent threads running and needing to use Hard-Drive file IO processes...

If this is blatantly unrealistic, what alternatives do you suggest? Thanks and sorry, I've never attempted anything with networking or like this before.

iForgotMyLogin
  • 111
  • 7

2 Answers2

1

Even if only doing a simple game, i would consider using a Message Broker. It adds network traffic with the package overhead but it's a incredible flexible and scalable.

Look at the Request-Reply pattern in messaging:

http://www.eaipatterns.com/RequestReply.htmlhttp://www.eaipatterns.com/RequestReply.html

And

Check out the RPC and Topic tutorial for this particular broker:

http://www.rabbitmq.com/java-client.html

You can subscribe a particular client to any Topic on an exchange, and they can be changed run-time. I imagine a Topic for clients looking for games, and then moving them to a unique top or que.

I realize it's off purpose, but consider it a more modern abstraction layer to TCP/IP than sockets. Much of what you want to do, is already done, and you'll have more time for the fun stuff! :-)

Peter Lindhard
  • 13
  • 8
0

I would suggest using a ThreadPool: http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml

With this you don't have to keep creating and destroying threads, but a number of threads are always there, sitting and waiting for tasks. This will avoid the overhead of creating and destroying threads.

With regards to IO, you would like to avoid reading the same disk from multiple threads concurrently, because this will cause the hard-drive to waste time seeking from one location to the other. I would solve this by implementing a class that manages file reads serially. Each of your threads can place a request on this class to read a particular file and provide a callback method to be called once the file is read. In your callback you can then process the file and come up with the response to be sent back to the phone. This will also ensure that you won't accidentally write to the same file in 2 threads.

This answer shows how to implement a task with a callback: https://stackoverflow.com/a/443741/1675231

Hope it helps.

Community
  • 1
  • 1
ValtsBlukis
  • 458
  • 3
  • 11
  • That sounds like good practice in general. Any idea on if a thread pool of 20,000 threads can be doing hard drive related tasks concurrently? Mainly reading text files. Or if the speed of that IO would clog up everything for all users. – iForgotMyLogin Nov 16 '12 at 01:07
  • I edited my original post to answer this question. – ValtsBlukis Nov 16 '12 at 02:29
  • If the phone sends a request, that is tossed to some serialized list of hard-drive tasks. The information is read, or written and a callback processes that information. Can the TCP socket (thread) remain open waiting for the response after all that? Lastly this would still entail having tens of thousands of threads waiting for a final retrieved and processed response. Is that bad to have so many individual threads/sockets open on the server while waiting for this HD I.O? Thanks – iForgotMyLogin Nov 16 '12 at 18:40