mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff MAURY <jeffma...@jeffmaury.com>
Subject Re: [MINA 3] UDP support
Date Fri, 22 Mar 2013 17:22:32 GMT
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.


On Fri, Mar 22, 2013 at 10:53 AM, Emmanuel L├ęcharny <elecharny@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


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message