I remembered few more details regarding question number 3. - the real reason I separated selector thread (A), from the main application thread (B) was to avoid data synchronization problems. I concluded that the best way to avoid data synchronization problems was to have only 1 thread (B) do any and all changes to the whole in memory data/state of the game (like player sessions, rooms, game states).
Thread B ended up processing 3 types of 'messages' from its input queue: 1. Incoming data from sockets - like "<join><roomid>4524</roomid></join>" - provided by the selector thread (A) 2. Time ticks - which are put at the front of the input queue every X milliseconds by a TimeThread. (hm, this would be thread type 'D' then :D) 3. Messages from the blocking backend application threads (type C), for example (String socketId, Type:FINISH_LOGIN, PlayerInfo playerDataFromDatabase) which means that socketId has sucessfullly authenticated (by querying the database, which is a blocking operation and needs to be done on a thread separate than B) as a player and that his data which was read from database needs to be incorporated into the data/state of the game. On Sun, Nov 21, 2010 at 10:01 PM, Borut Hadžialić <[email protected]> wrote: > Hello Mina users and developers. > > Over the past 5-6 years as a side job I wrote a few servers for > multiplayer Flash games in Java. As I started doing this back in > 2004-2005, while being a newbie Java programmer (so newbie I didn't > even know for ASF x_x) I have done everything by hand using the Java > NIO library, after getting some basic start code from a thread on SUN > forums called 'Taming the NIO circus'. > > About a year ago I saw Apache MINA and today finally got some time to > look into it. It looks very nice, with all those abstractions, > different transports, available filters and handlers and server > projects being built on top of it. > > I am wondering how hard would it be to switch my servers so they use > MINA for the socket layer. I have no problems with my current socket > layer - it works as it should for my specific server architecture - > but would like to try MINA because it looks like its mature and being > actively developed, and because it looks like it would allow me to > respond to new client requests much quicker in the future without > reinventing the wheel again.. > > My server architecture (the one built over Java nio) currently looks > like this - 3 types of threads: > A) single - selector thread - decodes and assembles socket read data > into application level messages (simple text markup) > B) single - application main thread - receives application level > messages from selector thread trough an array blocking queue and > processes them - holds all runtime data (eg. rooms, games, application > level player sessions, player positions, etc) to completely avoid need > for thread synchronization. Does only non-blocking operations. > C) many - backend application threads, which do blocking operations > like working with database, sending email, or querying some remote > service like facebook. > > Everything is connected with Java array blocking queues which exchange > simple value and command objects. Socket references are not passed > trough the queues - only simple string socket ids. > For example selector thread > - sends SocketMessage (String socketId, Type > (NEW,READ_COMPLETE,EXCEPTION,CLOSE,etc), Object attachment(a > whole/assembled text markup message) ) > - receives SocketCommand(String socketId, Type(WRITE,CLOSE,etc), > Object attachment) > > What I wanted to ask is: > > 1. Are there filters and handlers in MINA that can assemble simple > text markup (eg. <play><card>5</card></play>) from reading sockets and > send it to some queue. I saw that Vysper server mentions processing > xml stanzas, but couldn't find such filter in MINA source. > 2. Is there a way to give commands (eg. write(data), close) to MINA > sockets from another thread using some command messages? > 3. What do you think about the idea of separating thread types A) and > B) in servers? I don't remember any more why I did that in my servers > (I made that change 2-3 years ago, and this server work is my side > job), but I think that at that moment I removed all synchronized > keywords (and synchronization problems with them) from my application > level threads. The price I had to pay was that I no longer had access > to socket references - which I don't really need in application level > logic. This separation came in handy when I later had to implement a > game server that allow players to connect to same 'game space/realm' > over different protocols (eg. simple markup over tcp on one port for > Flash clients, and HTTP on other port for devices like IP-TV Set-top > boxes). > > Also, if someone has a list of open source and proprietary projects > that aim to make multiplayer game server development easier I would > appreciate it. > > -- > Why? > Because YES! > -- Why? Because YES!
