Awesome! Thanks! So then is it proper to handle this by using the session as a key?
ie. Let's say I wanted to save the contents of each input message in a string, one string per session, so that I can then parse the strings using my application's internal protocol. Then I could create a hashmap with the session as the key, and return the appropriate string from that hashmap to concatenate the appropriate input string to, and then my internal handlers would do whatever I need to do with those strings. Is that correct, or am I missing something? (I have a feeling I'm missing something and it's easier than this. ;-) ) Thanks, Michael ----- Original Message ---- > From: Emmanuel Lcharny <[email protected]> > To: [email protected] > Sent: Mon, January 25, 2010 3:44:43 PM > Subject: Re: supporting multiple clients with MINA > > Michael Clifford a écrit : > > I've been able to get the timeserver sample to work, and it looks like it > > will > do most of what I need, with some minor changes. But the one thing I can't > figure out is how to support multiple simultaneous clients. ie. I need some > way > to create multiple servers (one per client), > Hopefully not ! Oherwise, what would MINA be good for ? > > or to determine which client has sent some data so that I can route it to > > the > correct handler. > Simple : each client has its own session. > > If I can't do this, the incoming data might be interleaved. Is there a > > way > to do this? > It's all automatic. When the handler messageReceived() method is called, it's > for one single session. There is no way some other session's data will > interact > with another. > > In NIO, you can look at a key to see what connection data is associated > > with. > Is there a way to separate data by keys? > It's already done. A session is attached to each key. > > Do I have to create multiple server instances (one per client)? > > > That would be crazy :) > > Really, MINA does that for you. One simpe rule: one client, one session. One > hundred thousands clients, one hundred thousands sessions (it has been tested > up > to these numbers ;)
