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.

WDYT ?
Jeff



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
>
>


-- 
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

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