mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: [MINA 3] UDP support
Date Fri, 22 Mar 2013 18:04:20 GMT
Le 22 mars 2013 18:23, "Jeff MAURY" <jeffmaury@jeffmaury.com> a écrit :
> 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.

Just fyi, this is what we already do since mina 1.

> 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
> this can be handled as UDP does not guaranty the order of the messages.

UDP does guarantee that a datagram will either be sent fully,  or
discarded. From the user POV, as a datagram size is limited to 64k (and it
depends on the OS), if a bigger size has to be sent, it's up to the client
and the server to manage the ordering. Ie, it has to be handled by the
application protocol.

Her, the session has a different meaning. It's semantically another beast.
However we can perfectly create such a session, assuming that the end
points know how to deal with it.

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

Absolutely. Here, we already create a session, which may not be used at all.

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

Well, thus is pretty much what we do... But we can be smarter. For
instance, managing the session idleness often does not make sense in UDP.

Now, the base idea behind Mina is to hide all the plumbery so that the user
does not even have to know he is UDP or TCP based. Typically, this is what
we do on kerberos : the protocol switch from tcp to udp, but neither the
client nor the server care. They still do a session.write(message) to send
requests/responses. And that'S Rreally cool :)

> WDYT ?
> Jeff
> On Fri, Mar 22, 2013 at 10:53 AM, Emmanuel Lécharny <elecharny@gmail.com
> > 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
> > 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

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