On Fri, Mar 22, 2013 at 10:05 PM, Emmanuel Lecharny <elecha...@apache.org>wrote:
> Le 22 mars 2013 21:26, "Jeff MAURY" <jeffma...@jeffmaury.com> 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. > > Although it's for Mina a way to gather stats (nv msg sent, etc) and to > offer convenient methods (events). Nothing more. > In my opinion, you are mixing two different aspects. The statistics should be available globally for UDP, ie on the port level. > > > > > > Regards > > Jeff > > > > > > > > On Fri, Mar 22, 2013 at 9:12 PM, Julien Vermillard < > jvermill...@gmail.com > >wrote: > > > > > Hi, > > > comments inline > > > > > > On Fri, Mar 22, 2013 at 6:22 PM, Jeff MAURY <jeffma...@jeffmaury.com> > > > wrote: > > > > > > > I don't think we should try to map the session concept on top of UDP. > It > > > > think this is something that should be done at the user level. > > > > > > > > > > The whole MINA API is bound the the IoSession how you see UDP servers > > > without the IoSession ? > > > Directly read/write on the service ? with only one filter chain ? > > > > > > Let me explain a little > > > > Using UDP, as a server, the only information you have is there is one > > > > message (and not packet) from this address. > > > > If you map the session concept based on the remote address, I don"t > see > > > how > > > > this can be handled as UDP does not guaranty the order of the > messages. > > > > > > > > > > But you can add some IoFilter for doing that: reordering, > retransmission, > > > congestion control (well only if you really want to reimplements TCP on > top > > > of UDP :) > > > > > > So if you want to implement a session, this can be done only on the > user > > > > level where you must have something that will mimic what TCP does > > > > (ordering, retransmission,...). > > > > > > > It's perhaps simply a session but with the caracteristic of UDP : not > in > > > order, loss of some datagram.. > > > > > > > > > > So I would opt for a session-less solution but allowing to retrieve > > > > information needed (I think this is restricted to the remote socket > > > > address) to implement sessions on the user level. > > > > > > > > WDYT ? > > > > Jeff > > > > > > > > > > > > > > > > On Fri, Mar 22, 2013 at 10:53 AM, Emmanuel Lécharny < > elecha...@gmail.com > > > > >wrote: > > > > > > > > > Hi guys, > > > > > > > > > > I'm currently working on the UDP support for MINA 3. Here is the > way I > > > > > see the way to implement it, just tell me if you have any better > idea, > > > > > suggestion, whatever. > > > > > > > > > > First of all, there is a major difference between TCP and UDP : we > > > don't > > > > > have to manage an OP_ACCEPT event for UDP. That means we just > register > > > > > the socket on a selector for OP_READ events, and we process the > > > incoming > > > > > data on the fly. > > > > > > > > > > That has one direct consequence : we have to create the sessions > based > > > > > on the remote address, and we have to assume that a request coming > from > > > > > this remote address is associated with this session (in other > words, if > > > > > the server does not close the session, and if we don't manage iddle > > > > > sessions, we will keep a session for a remote address forever). > > > > > > > > > > So the algorithm would be somthing like : > > > > > > > > > > select() > > > > > for each selectionKey selected because of an OP_READ event > > > > > do > > > > > find the associated session, based on the remote address > > > > > if we get one, > > > > > then process the data generating a messageReceived event > > > > > else > > > > > create a new session > > > > > send a sessionCreated and sessionOpened event > > > > > process the data generating a messageReceived event > > > > > > > > > > This is a very rough description of how the main loop works. > > > > > > > > > > Some few valuable bits : > > > > > > > > > > 1) We need one single thread to manage all the incoming messages. > The > > > > > server will register the DatagramChannel on one single selector > > > anyway... > > > > > 2) As we use one single thread to process all the incoming > messages, we > > > > > wil have to spread the load after having read the data. We will > need an > > > > > executor for that (this is not mandatory, but this is the only way > to > > > > > scale). > > > > > As a consequence, assuming we use a pool of thread to manage the > > > events, > > > > > we need to guarantee that the messageReceived event is processed > > > *after* > > > > > the sessionCreated and sessionOpened events. > > > > > 3) One idea is to associate an event queue to each sessio. When we > > > > > create the session, we push three events in this queue : the > > > > > sessionCreated event, then the sessionOpened one, and finally, the > > > > > messageReceived event. Then we can peek a thread and let it process > the > > > > > events. > > > > > 4) Or we can associate one single thread to the session ( a bit > like > > > > > what is done in MINA 2). It could make sense if we want to order > the > > > > > event processing. I prefer the previous solution though. > > > > > > > > > > So, wdyt ? > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > -- > > 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 > -- 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
