Ahh, ok. I may be thinking about it differently, because my program is not just serving lots of hosts. It's taking data from each individual host and combining them using some fairly complex logic, so eventually, I must get my data out of the sessions, and into the core of my program.
So let me see if I understand this correctly: 1) Every time something connects to my server, a session is automatically created. I don't have to do anything extra to create it. 2) Sessions contain all of the info about a connection 3) When something sends a message to one of my sessions, that session is automagically called. I don't need to do anything, and I don't need to iterate over them. 4) I can write a filter to have the session do the parsing for me, so I just need to handle the string that it outputs if I choose to do that. Is that correct? So then if I store the string as an attribute, I would need to place each new session into a container, and then iterate over all the sessions, read the strings out of them, and do something with those strings? Then I'd also need to check each session to see if it was connected, because it might have closed in the mean time, and then I'd want to read out the last string and stop tracking it. Thanks, Michael ----- Original Message ---- > From: Emmanuel Lcharny <[email protected]> > To: [email protected] > Sent: Mon, January 25, 2010 4:23:05 PM > Subject: Re: supporting multiple clients with MINA > > Michael Clifford a écrit : > > 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. > Why don't you implement the protocol as a filter ? Then your application will > receive a complete valid and decoded message, and no need to do that matching. > > 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. > > > if you decide to do that, then store the String in the session, as an > attribute.
