I think it is a little different on the client side because you need a session to be able to store a socket address. Maybe the API is not adequate for ADP.
Jeff On Sat, Mar 23, 2013 at 7:29 AM, Emmanuel Lécharny <[email protected]>wrote: > Le 3/23/13 7:16 AM, Julien Vermillard a écrit : > > Le 22 mars 2013 23:35, "Emmanuel Lécharny" <[email protected]> a > écrit : > >> Le 3/22/13 10:51 PM, Jeff MAURY a écrit : > >>> On Fri, Mar 22, 2013 at 10:05 PM, Emmanuel Lecharny < > > [email protected]>wrote: > >>>> Le 22 mars 2013 21:26, "Jeff MAURY" <[email protected]> a > écrit : > >>>>> Sorry, I missed my point. > >>>>> My intent is not to remove the session concept from the MINA UDP API > > but > >>>>> rather to say that trying to implement the concept of a virtual > > session > >>>>> like Emmanuel proposes seems to me that this will put some kind of > >>>> overhead > >>>>> in the MINA processing (and maybe memory leaks as well) for a use > case > >>>> that > >>>>> I don't see being relevant except for 1% > >>>> What we call a 'session' here is just a container with a state. If the > >>>> application does not want to do anything with it, no pb. > >>>> > >>> What I try to explain is that you are implementing a session for a use > > case > >>> that I think is very specific. > >> Yes, but this is the way the MINA framework is designed : we have > >> session in the IoHandler... > >> > >> Now, I wonder if we really need to manage Session instances when we have > >> incoming UDP messages : wouldn't it be better to propagate a static > >> Session instance that only contain the scoketAddress from the caller, > >> taken from a pool of session instances ? > >> > >> I guess that it's what you have in mind... > >> > > Static session would make a lot of sense for broadcast or multicast. > Sorry, I meant pre-allocated, not static. As we store some informations > about the caller (remote address/port) in the session, it's not possible > to use a static session. > > In any case, I think we have to propose a unmanaged UDP server (where we > don't manage idle, nor stats), and an optionnal managed UDP server, as > suggested by Jeff. > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > > -- Jeff MAURY "Legacy code" often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
