Hello,
I post a source of my NIO server and NIO client based on Reactor Pattern for a realtime game massive players.
The db is JE for keep data in memory in the server (not in xml (is too slow :x))
TCP and UDP connected mode ! for really speedup data transfert :D
Nio is the only way for serious server games based on java who have same result test of c++ :evil:
sorry for my poor english :lol:
the code is here : http://62.147.164.155
Have fun ^^
Thank you for jMonkey project i love it XD
(No offense intended to you lbrinon, but just in case anyone finds your link suspicious looking, I can assure everyone it's been searched and confirmed clean)
Thank you for the contribution lbrinon! We have a couple other avid network coders around here whom I hope to see drop by this thread to discuss your work 
Thank you for the code, we will certainly have a look at it! Love to see somebody giving back to jme 
Cheers,
Normen
Thank you,
the code is checked for the moment a project perssonnel for more urgent, I will reorganize all this and adapt an example of the tutorial jm3 nio to combine with a client server and n * and post something with its own documentation I used some good JE and NIO.
I am not only contains a good programmer 3d, and I study at the moment this new world, so I will take some days to do it and test it in multi-users only real requirement and i post source of course
Well actually there is no need for txp+udp actually,
I only use udp and implemented a own reliable protokoll on it, works kinda exaclt the same, however is still able to use udp holeing.
Storage of data is not part of the low level part, the high level part uses networkids (individual id for object, can be reused if object not existant anymore, so up to int.max objects), I use no expecit keyvalues to synchronize stuff, instead it is event based, (move event, explodeevent,inputevent,ect) For each object it is possible to set a unreliable transmit mode and constant updates (for player movement for example) or a reliable update (like a tree, that rarely ever changes) Also it is possible for each eventtype, to define if it must be reliable even for unreliable objects (money in an rpg for example)
Reliable events/objects are only updated on changes.
Low level the whole system serializes over a own system the values/Message objects directly into a bytearray, (with defined max size) and sends them as an udp packet. It also makes sure reliable messages arrive inorder,onlyonce and at least once. (exactly once)
Yes I understand the gist of your post, though I never practiced the art of the serialized object because everyone knows that while it is easy to implement it takes an awesome time and can not be question in a context of real time.
There he must first think of a solution for storing the ByteArray to a transfer to nio native ByteArray with one call to copy.
Regarding the top level, I agree no surplusage loading of objects and only packaged shipments by user actions or AI objects to this in the client.
However that your message arrives in the order in udp mode it means that your server is processing the information one by one and that this is due to protocol 'handmade' in the coding or udp server itself, it raises obvious concerns load balancing and is contrary to the basis of the Reactor pattern.
Do you have a source you could share? thank you phoenix