dev@grizzly.java.net

Re: Strange behavior of Grizzly

From: Minoru Nitta <minoru.nitta_at_jp.fujitsu.com>
Date: Wed, 03 Jun 2009 08:43:28 +0900

Hi Bongjae,


 Thank you very much for your quick reply and curiosity. I understood
your proposal. Then, I would like to write my opinion.

 In UDP, it should be possible to send packets from a port where
server socket is already bound. For example, after starting my SIP server,
UDP ports status is like

[root_at_rx200-4 ~]# netstat -a -u
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 *:666 *:*
udp 0 0 *:669 *:*
udp 0 0 *:sunrpc *:*
udp 0 0 *:ipp *:*
udp 0 0 rx200-4:5060 *:*

where

udp 0 0 rx200-4:5060 *:*

is a server socket where my SIP server is listening to from any other
addresses (*:*). Then after sending packets from the same port (i.e. 5060),
the status is like

[root_at_rx200-4 ~]# netstat -a -u
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 *:666 *:*
udp 0 0 *:669 *:*
udp 0 0 *:sunrpc *:*
udp 0 0 *:ipp *:*
udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED
udp 0 0 rx200-4:5060 *:*

where

udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED

is a client socket which receives packets only from [UNKNOWN]:6677.

So if packets are sent to the port 5060, the client socket is used
if the sender address is [UNKNOWN]:6677 and the server socket is used
if the sender address is not [UNKNOWN]:6677.

I thought that the following code you mentioned in your reply makes
the

udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED

socket. But, I am not sure.

Minoru

> Hi Minoru,
>
> I saw your app curiously and I could reproduce your problem.
>
> When I debugged your program, I could know that your problem was perhaps caused by duplicated socket binding.
>
> I think that it is better that the client controller doesn't use a local address when it connects remote peer.
>
> See the following:
>
> In ConnectionManager.java
> ---
> private ConnectorHandler createHandlerUDP(...) {
> ...
> try {
> //connectorHandler.connect(socketRemote, local, callbackHandler);
> connectorHandler.connect(socketRemote, callbackHandler);
> } ...
> }
> ---
>
> In my opinion, the server controller's socket which was already binded with a local address could have a problem if a client tried to bind own socket with the same address locally.
>
> I could see that your program's server couldn't receive any packets though blocking DatagramSocket(UAC and UAS) sent a packet to the server controller successfully.
>
> So I thought that maybe the server had a problem.
>
> It is not certain. :-)
>
> But, I hope that my proposed patch and my words help you.
>
> Thanks!
>
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
> To: <dev_at_grizzly.dev.java.net>
> Sent: Tuesday, June 02, 2009 5:28 PM
> Subject: Strange behavior of Grizzly
>
>
> > Salut,
> >
> >
> >
> > I have been encountering a strange behavior of grizzly, and I need help.
> > I tested the enclosed program and it sometimes worked fine and it sometimes did
> > not work well. When it works, it repeats sending requests and responses,
> > but when it does not work well, it stops repeating.
> >
> > I have no idea where is the problem (my test program or grizzly).
> > I tested it on grizzly version 1.9.12 to 1.9.16 and the result was same.
> >
> > Thanks.
> >
> > Minoru
> >
> >
>
>
> --------------------------------------------------------------------------------
>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net