mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 이희승 "(Trustin Lee)" <trus...@gmail.com>
Subject Re: [mina] Sending datagrams without connection
Date Mon, 18 Feb 2008 05:10:34 GMT

2008-02-09 (토), 13:06 -0600, David M. Lloyd 쓰시길:
> David M. Lloyd wrote:
> > Wilson Yeung wrote:
> >> It would be quite nice to be able to do something equivalent to 
> >> sendto() with
> >> a DatagramAcceptor or a DatagramConnector.
> >>
> >> I've written a UDP application based on Mina that sends precisely 1 
> >> packet
> >> to 1 million end points, and waits for 1 packet from 1 million end 
> >> points. Each 2 packet exchange is 1 Mina IoSession, and I continuously 
> >> reuse the
> >> same 1000 - 5000 prebound IoSession objects, that is, I keep 1000 - 
> >> 5000 of
> >> these exchanges in flight at a time.
> > 
> > My opinion is that there should simply be one IoSession for all datagram
> > sockets.
> 
> Let me clarify - I mean one IoSession for *each* datagram socket.

David and I met in the JBossWorld 2008 and had some time to discuss
about this issue, and the following is my idea after the discussion with
him.

If we map one IoSession to one DatagramChannel, it means we need to
provide additional information (i.e. remoteAddress of the received
message) when messageReceived event is fired.  There are a few solutions
to this issue:

1) Add SocketAddress parameter to messageReceived - it's not so good
because TCP/IP transports will never use it.
2) Change the datagram transport to use other type than IoBuffer.  For
example, provide a class that contains an IoBuffer and SocketAddress -
it's also not so good because it breaks backward compatibility and
prevents a user from migrating from TCP to UDP and vice versa.  Their
IoHandler implementation will not be reusable.

Another problem is that we already have IoSession.getRemoteAddress().
If we map one session to one datagram channel,
DatagramSession.getRemoteAddress() should return something ambiguous
such as null, which causes backward compatibility issues.

Actually, having more than one sessions per datagram channel is similar
to the solution #2 above in that IoSession behaves a kind of wrapper of
an extra information.  The problem here is the creation and destruction
overhead of DatagramSessions.

So... I'd like to suggest to keep the current API while minimizing
creation overhead.  We definitely need to improve performance for
datagram transport and see if how it compares to the plain NIO
implementation.  If the performance tuning attempt fails, we could think
about revamping the overall API which might be pain to users.

-- 
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Mime
View raw message