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/
signature.asc
Description: This is a digitally signed message part
