We Keep Coding

Implementing a data driven simulated clock in java?

In my simulation project i am simulating web requests through Runnable objects that either sleep for specified milliseconds or keep processor busy through spin. But the response times of simulated http requests are little more than expected due to impreciseness of Thread.sleep() and i want to replace this pause with some other technique. I cant use spin as it will eat cpu-cycles also i need to simulate an I/O boundness by taking a pause. I have searched alternatives of sleep and could not find to take a pause in java other than Thread.sleep,spin or wait. I cant use wait as it is also imprecise. No guarantee of precise times in wait too. In answer#2 of this question Peter Lawrey talked about data driven simulated clock, but i have also search about it but did not find any tutorials or its implementation in java. Is there any one who can just give a simple example in java how i can implement my own dta driven simulated clock so that i can take myself out of Thread.sleep() trouble.

Session Oriented Asynchronous Architecture using Actors/AKKA

The application we are building has a very simple concept: it receives incoming events from a Database and for each event it opens an interactive session with clients (in the event) by showing a menu. Based on client response, we move to the next state or take some concrete action (e.g. transferring funds).
Sessions are independent of one another. For example, suppose we get two events from the database saying clients A and B have reached a zero account balance state. In response to this event, we establish two connections to A and B show a menu which looks like the following:
Please select an option:
1. Get $5
2. Get $10
3. Ignore
For options 1 and 2, we ask for confirmation in the form of second menu.
Are you sure?
1. yes
2. no
In this case, we'll have two sessions. Client A might choose option 1 (1. Get $5), whereas Client B chooses option 3 [in the first menu]. In the case of Client A, we'll present the second menu (above) and if the response is 1. yes, we'll take some concrete action such as transferring funds and closing the session.
All client communication is done by a 3rd party system which takes JSON including client address, menu text and returns a response back to us. It takes care of actually maintaing the session on the wire, whereas we only need to do response correlation and dealing with session states.
We're expected to handle 50,000 of such sessions in parallel.
Earlier, we designed the system in Java using SEDA model. Having heard of Actors, we are willing to check them out and write a quick PoC project (Java/AKKA). My questions are:
Has anyone had experience in building such kind of an application? Is 50,000 simultaneous sessions too much for AKKA to handle? (Note, we are only waiting for the response. When the response comes, based on the answer, we jump to the next stage, so it should be possible).
Which architectural stye/paradigm which best suit this problem in AKKA? Are there any frameworks out there for this kind of problem?

This is actually a reasonably easy use case with Akka's clustering. 50K sessions represented as an Actor instance for each is not very high load. The reason to use clustering is only for fault tolerance.
The idea behind the architecture would be to have a web tier for handling RESTful requests that correspond to the sessions. These requests would be sent to the Akka cluster and routed to the appropriate session Actor by session ID, or a new one would be created. When a session is done, you stop the actor that is associated with it.
Note that the session actors should send themselves timeout messages via the scheduler. Upon completion of handling a new message, the actor should schedule itself a message via the ActorSystem scheduler for 15 minutes (or whatever your timeout is). When a new session message is received, that scheduled task should be cancelled, the new update handled, and then a new timeout scheduled. There is a plausible race condition here, in that a timeout message may be in your session actor's mailbox queue AFTER a session message, but if your timeout message includes a time of when it was scheduled (the 15 minutes ago), you can check that and ignore it and reschedule another (just as a safety mechanism to avoid a memory leak). If the time is greater than 15 minutes ago, then you stop the actor.
To see how the distribution of work to the session actors would be implemented, please see the "Distributed Workers with Akka and Java" template in Typesafe's Activator. You will have a fully running clustered Akka application that you can tailor to do the session management as I've described above. You can then export the project and work on it in Eclipse/IntelliJ/Sublime/TextMate/etc. To download Activator, see here.

Identifying threads in game (TCP related also)

This is a school project, please do not provide any code, I am only looking for hints to guide me in the right direction.
Write and test a game server that clients subscribe to. Once subscribed, the client receives
a list of games (the same game, just different 'instances' of it) currently in play. The client may then elect to join a game or start a new
one. A game must have at least two players before actually starting. The system must support multiple clients all playing one game, or multiple clients playing multiple games.
The objective of this project is to gain experience in Java, TCP, and threading.
My current design and implementation has 2 files: server.java and client.java
The server file has 3 classes: Server, Lobby and Game
The client file has 1 class: Client.
The implementation of the "game" is trivial, I am fine with that.
Currently, the server class establishes the TCP connection with the client class.
Each time a client is instantiated, the socket is accepted in the server class, and the program continues.
Continuing on, the server class creates the lobby class.
The lobby class is where I am having trouble with. By default, I am creating 1 "game" object, and passing in the clientSocket:
game g = new game(clientSocket, playerID);
g.start();
The game class extends thread, which I think is the correct way of doing it. Each "game" will be a separate thread, so to speak, so players A and B can share 1 thread, and players C and D can start a new game with another thread.
I am new to threads, but this is the best implementation I could think of. I ruled out having multiple threads for lobby's, since that doesn't really make sense, and multiple threads for clients is pointless too, so I think multi-threading the games class is ideal.
Right now, when I create 2 instances of the client, they are both joining the same 'thread' (they are both in the same game and can talk to each other).
How am I supposed to do it so that, a new player can type "new" or whatever in the lobby and create a new "game", where it's a new thread.
I'm sure I mis-understood certain parts about threading or whatnot, but I appreciate any help.

I wouldn't map games to threads. Instead, map clients to threads. Each client will have their own thread that does work initiated by the receipt of commands from that client. When you need to create a new game, just create a new object in a shared collection of games. Track, in the client instance, which game, if any, it's associated with.
If you find you really do need a thread to manage a game, then you can create one. When a client sends a command to a particular game, just put that command on a queue of commands that's read by the thread managing that game. The game thread only needs to know which game it's managing. It can terminate itself when that game is finished.

Firstly, I would suggest you read on multiplayer game development and networking in Java (UDP/TCP). I am no game-developer but simply happenned to take a Java networking course in college and had a similar project (a networked game).
Secondly, dealing with multiple threads is proportional to complexity. You want to minimize complexity. I would suggest to abandon an "I have to find a place to use threads" mentality. (Don't force a square peg in a round hole ;))
Continuing, following through the requirements:
Write and test a game server that clients subscribe to.
IIRC, this is fairly straightforward (and you're probably past this part).
Once subscribed, the client receives a list of games (the same game, just different 'instances' of it) currently in play
This should be fairly straightforward as well since a TCP connection between the server and client have been established already.
However, there are a couple of things to understand at this point. The most important, perhaps, is that there will be a single central server that will hold information on all connected clients and existing games. This consequently means that it has to be the one to deal with the state of the system (e.g. tracking currently existing gamerooms), client requests (to create/join gamerooms), as well as updating clients with relevant info on the system's state (e.g. created/closed gamerooms).
Another consideration at this point is the scope of client's functionality in the system. A typical implementation would probably be a fat-server, thin-client architecture. Basically, this means that a client does no real processing of data (from user input) and instead relies on the server. Most of the time, then, the client is only waiting for input from user or a response from the server. On the otherhand, the server deals with the processing of data from clients, updating the system state (including individual game states), and notifying concerned client of relevant changes in the system/game state.
The client may then elect to join a game or start a new one
What actually happens here is a client sending data "I elect to join a game" or "I elect to create a game" to the server. The server acts on this and notifies concerned clients (I say concerned and not all since some clients could possibly be playing and do not need to know whether new games have spawned).
A game must have at least two players before actually starting.
-
The system must support multiple clients all playing one game, or multiple clients playing multiple games.
Again depending on the client-server architecture, either the server will be doing all the processing (fat-server, thin-client) or the clients (thin-server, fat-client) do the processing while the server mainly serves as a relay point to other clients. I have no definite (or even confident) suggestion on this, however, as I am simply overwhelmed by the sheer number of possible implementations and their consequences. Thus, I can't really encourage enough to read more on networking and game development. Individually, those 2 topics are incredibly vast, much more when combined.
Lastly, with regards to the use of threads. IIRC, dispatching separate threads for opened sockets are useful in preventing the application from getting blocked waiting for input. I don't really agree with your idea of "hosting" a game in a thread but since you're in school I can only admire your trying things out.
This may help you further: Lesson: All About Sockets. And you might perhaps also be interested in UDP.

Best way to handle many incoming packets

I'm currently developing a simple P2P network as an exercise. Each node in the network sends heartbeats to a subset of the other nodes to be able to detect nodes that have left the network. Beside the heartbeat packets I send packets when new nodes join/leave the network, when they want to locate a resource (small text files), etc. All packets are UDP packets.
Whenever I receive a packet I start a new thread that handles that specific packet. I am however concerned with the amount of threads I start during one applications lifetime which adds up to quite a lot (Especially because of the heartbeats). (There is also the risk of deadlocks and the like I would like to avoid).
I thought about having a queue or something where I put all incoming packets and have a single thread handling all packets one at a time from that queue (something like the producer-consumer pattern). I would like the packets to be handled rapidly so the sender doesn't think the packet is lost.
What is the best way to handle a lot of different incoming packets without having to start a new thread for each of them? Should I go with what I have, the producer-consuming or something different?

How long does it take to your application to process one packet?
For the ping ones it is probably faster to just process them as they are received, you can put the others in a shared data structure such as a particular blocking queue, so when the queue is empty the worker threads wait for new jobs, and when a new jobs is added, a thread is awaken and will do the job.
Probably starting one thread per packet makes you consume more time on starting and stopping the threads than in actually doing the job.
If the things to do in response of a packet aren't so time consuming for all the type of packets, it might be the case that the extra time spent with the locks of the queue and scheduling threads makes your program slower rather than faster.
In any case use thread pool and start the workers in the beginning. If you want you could increase or reduce the number of working threads dynamically depending on the load of the past minutes.

I would use an event driven architecture. Creating a new thread for every packet is not scalable, so this will work to a certain amount of workload, but there is a point it won't work anymore. You could compare that to e.g. a chat program like the Facebook chat where messages are the packets.
An event driven architecture would be scalable and IMHO exactly what your looking for. Just do some googling, there libraries for many programming languages, so just pick the right one for you (I like to do that in Erlang, Scala, C or Python).
edit: ok, didn't see the java tag. But the language does not matter.
Take a look at this link for example:
http://www.nightmare.com/medusa/async_sockets.html
I find it a quite good one to get the idea of event driven programming.

Is this a good multi-threaded server design?

I have a server for a client-server game (ideally the basis for small MMO) and I am trying to determine the best way to organize everything. Here is an overview of what I have:
[server start]
load/create game state
start game loop on new thread
start listening for udp packets on new thread
while not closing
listen for new tcp connection
create new tcp client
start clients tcp listener on new thread
save game state
exit
[game loop]
sleep n milliseconds // Should I sleep here or not?
update game state
send relevant udp packet updates to client
every second
remove timed out clients
[listen for udp]
on receive, send to correct tcp client to process
[listen for tcp] (1 for each client)
manage tcp packets
Is this a fair design for managing the game state, tcp connections, and send/receive udp packets for state updates? Any comments or problems?
I am most interested on the best way to do the game loop. I know I will have issues if I have a large number of clients because I am spawning a new thread for each new client.

That looks like a reasonable start to the design. It wouldn't be bad to go beyond 10 clients (per your comment) in terms of scaling the number of threads. As long as the threads are mostly waiting and not actually processing something you can easily have thousands of them before things start to break down. I recall hitting some limits with a similar design over 5 years ago, and it was around 7000 threads.

Looks like a good design. If I were you I would use an existing nio framework like netty.
Just google java nio frameworks and you'll find several frameworks with examples and documentation.
Update
Thanks, but I prefer to do it all on my own. This is only for a side project of mine, and much of its purpose is
imho you'll learn more by using an existing framework and focus on the game design than doing everything by yourself from start.
Next time you'll know how do design the game and that makes it easier to design the IO framework too.

I'd say that (especially) in Java, threads are more for convenience than for performance (there are only oh-so-many cores, and I guess you'd like to keep some control on which threads have priority).
You haven't said anything about the volume of message exchange and number of clients, but you might want to consider more natural from the perspective of having a single thread handling the network IO, and having it dispatch incoming requests in a tight loop, and mapping the ACTUAL work (i.e. requests that you can't handle in the tight loop) to a thread pool. IIRC, in such a setup the limiting factor will be the maximum number of TCP connections you can wait for input on simultaneously in a single thread.
For increased fun, compare this with a solution in a language with has more light-weight threads, like in Erlang.
Of course, as #WhiteFang34 said, you won't need such a solution until you do some serious simulation/use of your code. Related techniques (and frameworks like Netty where you could find inspiration) might also be found in this question here.
There is a certain cost to thread creation, mostly the per-thread stack.