Channel open event for UDP and TCP on bind

["Trustin Lee (이희승)"]

fps wrote:
> 
> Trustin Lee wrote:
>> It is an expected behavior.
>>
>> In a TCP server, a channel is open only when a client connects to it.
>> To be more precise, a server socket gets the initial channelOpen event
>> on bind, but it is hidden by ServerBootstrap.  What you deal with in
>> your handler is the channel accepted by the server socket.
>>
>> In a UDP server, a channel is open immediately on bind and you can
>> receive and send the UDP packets without accepting anything because
>> there is no notion of connection in UDP.
>>
>> Simply, think about writing a TCP or UDP server by yourself.  When you
>> write a TCP server, you accept a new socket from a server socket and
>> then use the accepted socket to communicate with the client.  When you
>> write a UDP server, you simply create a socket bound to a port and then
>> keep using it to communicate.
>>
> 
> Thx Trustin for your quick reply, as always :)
> 
> At least I know I'm not imagining things which is good ;)
> Having said that I understand the difference between the non-connected
> nature of UDP and the connected nature of TCP but the difference in
> behaviour of bind(..) rattles me somewhat :)
> 
> For TCP the server will trigger a channel open event upon connecting a
> client which is fine then whatever the client decides to send is received.
> For UDP when a client sends the first message wouldn't it make sense at that
> point to trigger first a channel open followed by receiving the message?
>
> This way the bind(...) behaviour is consistent and the channel open event
> for UDP (triggered at the same time as the first message is received) would
> allow to get the remote address from the channel (in the channelOpen(...)
> method as per TCP) which is not the case with the current behaviour.

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

HTH,
Trustin

-- 
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/20100107/2c5d0862/attachment.bin