So after reading some material regarding nonblocking IO I've decided to write a server with NIO. In traditional, blocking IO, I was having a seperate thread for each of my clients, so I always knew what client sent me what data. But now, I just select a readable key and read it's data. How do I know which client sent what data? Is it efficient to make a HashMap where keys are SocketChannels and values are references to my Client objects? Or is it secure to give each client an unique ID and require them to communicate by always sending it?
Looking forward for your comments.
I dug into this a few months ago, what the servers I found were using as an idea of a Session,.....uh, it needs work.
NIO is popular, and has some good work. I expect it will rely on existing pardigm of what a session is, thus multiple connects from one machine would appear as one session, not exactly what I thought of as a sesssion.
I suggest a synchronized block on entry, writing a session key at random if none ... then do something along the lines of what you are thinking but be sure to do the lookup on the key in that block - doing so on the session key that reads on the SocketChannel. Dicey I would think, not for scaling and commercial app.
Use SecureRandom, generate a Key. Pass that key to a HTTP 1.0 GET ... just come up with another one and look for it to come in as POST - doing so by writing the key to <form> ('s) keeping in mind that a web is the work of spiders .... don't expose yourself to spider bites.....
This design challenge has a issues in scaling and server load. If requests come in as much as a hundred a second at some point, some designs will bog ( or lose keys ) so it matters much if this is a student project or a deployable commercial app. Several things have been fixed in 5.0 6.0 and 7.0 - that does not matter much to me, I still plan on calling into a dll through jni when I can get the skills to do it, too many times something that is simple and obvious only gets surface treatment: Try hardcoding a line ending as \u000a or whatever it is, watch and moan.....
See the SelectionKey.attach() method. You can use this to attach some "state object" to the SelectionKey representing the "conversation" with the client in question (and the attachment() method retrieves the state previously attached).
Thanks for your posts. Helps a lot ;)