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 20:25:11 GMT
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%

Regards
Jeff



On Fri, Mar 22, 2013 at 9:12 PM, Julien Vermillard <jvermillard@gmail.com>wrote:

> Hi,
> comments inline
>
> On Fri, Mar 22, 2013 at 6:22 PM, Jeff MAURY <jeffmaury@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 <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
> >
>



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