Channel open event for UDP and TCP on bind

["Trustin Lee (이희승)"]

fps wrote:
> 
> Trustin Lee wrote:
>> Again, TCP uses one server socket plus many accepted sockets, but UDP
>> uses only one server socket to communicate with multiple peers.
>>
>> In MINA, I did some sort of emulation similar to your suggestion; MINA
>> created multiple virtual session objects for each remote address.
>> However, there is no such virtual sessions in Netty anymore - one Netty
>> Channel is supposed to handle all messages from all remote addresses.
>>
>> To get the remote address of the packet in UDP, you can call
>> MessageEvent.getRemoteAddress() at messageReceived().
>>
>> So, why no more virtual sessions?  It's because:
>>
>> 1) we cannot assume a UDP applications communicate using the same remote
>> address because not all UDP applications emulate connection-based
>> communication.  You can receive from port 1234 and then send the
>> response to port 5678 for example.  To do that, you had to create
>> another virtual session in MINA, which is obviously impedance mismatch.
>>
>> 2) the virtual sessions require the emulation of session life cycle,
>> which leads confusion and complication to UDP programmers.
>>
>> Hence, the current behavior of UDP transport fits much better to how UDP
>> works actually.
>>
>>> I may be overlooking some other aspects of the architecture of Netty so
>>> please excuse me if the above doesn't make sense.
>> No problem.  It led me to some food for thoughts. :)
> 
> Thx Trustin.
> 
> So following up on the above I'm assuming that the pipeline for a TCP based
> protocol compared to a UDP based protocol cannot be the same.

Yes.  You could make some handlers (e.g. codec?) work with both
transports though.

> For example where FrameDecoder or ReplayingDecoder would be used for a TCP
> based protocol in order to decode a message as more bytes come in I take it
> that for a UDP based protocol we just need to deal with messageReceived(...)
> in an UpstreamHandler and that the message received is the full datagram
> packet. Effectively for a UDP based protocol you get nothing or everything
> (i.e. the entire message).
> Is that correct?

Yes.  Using FrameDecoder and ReplayingDecoder are not needed for UDP,
but if your decoder should work for both TCP and UDP, it doesn't harm to
use them anyway.

HTH,
Frederic

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100109/b8b8da03/attachment.bin