Channel open event for UDP and TCP on bind

[fps]

Trustin Lee wrote:
> 
> 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
> 
> 

Thx for the replies. I've sorted it out now and both TCP and UDP use the
same ReplayDecoders.

Fred

-- 
View this message in context: http://n2.nabble.com/Channel-open-event-for-UDP-and-TCP-on-bind-tp4260514p4290763.html
Sent from the Netty User Group mailing list archive at Nabble.com.