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. 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. 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,...). 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
