Hi Minoru,
Thank you for your kindness.
Minoru wrote:
> I tested by modifying DatagramSocketClient like the above(*).
I see.. I tried to test the my test program on linux, I could meet BindException, too.
Bongjae wrote:
>So I thought that BindingException would not be occurred between any address and specific address and the DatagramSocketClient didn't need setUseAddress.
This is only on Windows. You are right.
Minoru wrote:
> Yes, DatagramSocketClient sends a packet to the port 9090 of the local machine.
> At first, a server controller starts, a server controller receives a packet
> from the DatagramSocketClient (of course).
> Then, connector handler that is acquired from client controller connects to port
> 9090. At this point, there are two Controllers which listens to the same port
> 9090. One is a server Controller and the other is a client controller.
> The server Controller should receive any packets from any addresses, because
> it listens as *:9090. The client controller receives packets only if a
> sender port number is 9090.
The server Controller didn't listen as *:9090 but specific_address:9090.
I could also see the netstat like this.
---
udp 0 0 0.0.0.0:9090 0.0.0.0:* --> DatagramSocketClient's binding info
udp 0 0 61.77.153.200:9090 0.0.0.0:* --> Server and Client Controller's binding info
---
When I tested it on Linux, I could know that last bound channel was always enabled like your test. So receiver's switch is correct as your test result.
You can also see this if you modifies the following code.
In DatagramSocketClient
---
private DatagramSocketClient() ... {
client = new DatagramSocket( null );
client.setReuseAddress( true );
//client.bind( new InetSocketAddress( PORT ) );
client.bind( localInetSocketAddress ); // this is specific server's address
}
---
Then,
1. The server Controller binds specific address.
2. DatagramSocketClient binds the address again.
3. DatagramSocketClient starts to send packets.
4. The server Controller doesn't receive any packet because maybe DatagramSocketClient will receive the packet. (DatagramSocketClient don't have receiver)
5. The client Controller try to connect and bind the address again with Controller#acquireConnectorHandler() .
6. The client Controller receives packets.
So last bound address which the client Controller tried to bind was enabled in the end. Of course, on Windows, we can't detemine what channel will receive the packet. (Sometimes the server Controller, sometimes the client Controller or etc...)
Do you agree?
Minoru wrote:
>Then, when DatagramSocketClient sends a packet to port 9090 of the local machine,
>I think client controller should receive the packet, because the sender port
>number is 9090.
What do you mean "the sender port"? Does "the sender port" mean DatagramSocketClient's port? or Controllers's port?
If you mean DatagramSocketClient's port, I don't think that the client Controller should receive packets because the sender's info is not important but sender's destination info is important.
If you mean Controllers' port, is it your expectation that last bound address should be always enabled?
In other words, I think that maybe a common user don't consider what is the last binding information and receiver can be switched.
What do you think?
If I am misundertanding, please let me know again. :)
Thanks.
--
Bongjae Chang
----- Original Message -----
From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
To: <dev_at_grizzly.dev.java.net>
Sent: Friday, June 12, 2009 1:38 PM
Subject: Re: Strange behavior of Grizzly
> Hi Bongjae,
>
>
>> Hi Minoru,
>>
>> I have a question and maybe I didn't understand your words clearly.
>
>
> I tried to be consistent to the problem, but I feel sorry if you
> are confused. Let me clarify.
>
> One point, I must correct what I said.
>
> private DatagramSocketClient() throws SocketException {
> client = new DatagramSocket( null );
> client.setReuseAddress(true);
> client.bind( new InetSocketAddress(PORT)); <---(*)
> }
>
> I tested by modifying DatagramSocketClient like the above(*).
>
>> I thought that receiver's switch was a problem for you like this.
>>
>> > current thread: Thread[server-WorkerThread(9),5,Grizzly], Request: hello world-6
>> > current thread: Thread[server-WorkerThread(10),5,Grizzly], Request: hello world-7
>> > ###Binding duplicated socket again..###
>> > current thread: Thread[client-WorkerThread(6),5,Grizzly], Request: hello world-8
>> > current thread: Thread[client-WorkerThread(7),5,Grizzly], Request: hello world-9
>>
>> But you means that it is a problem that receiver is not switched like this.
>>
>> > current thread: Thread[server-WorkerThread(6),5,Grizzly], Request: hello world-5
>> > current thread: Thread[server-WorkerThread(7),5,Grizzly], Request: hello world-6
>> > current thread: Thread[server-WorkerThread(8),5,Grizzly], Request: hello world-7
>> > ###Binding duplicated socket again..###
>> > current thread: Thread[server-WorkerThread(9),5,Grizzly], Request: hello world-8
>> > current thread: Thread[server-WorkerThread(10),5,Grizzly], Request: hello world-9
>>
>> Right?
>
>
> Regarding the above, "the receiver is not switched" is the problem for me.
> I think this behavior, unlike on Linux, is not correct.
>
>> I thought that DatagramSocketClient should send the packet to the same server.
>
> Yes, DatagramSocketClient sends a packet to the port 9090 of the local machine.
>
> At first, a server controller starts, a server controller receives a packet
> from the DatagramSocketClient (of course).
>
> Then, connector handler that is acquired from client controller connects to port
> 9090. At this point, there are two Controllers which listens to the same port
> 9090. One is a server Controller and the other is a client controller.
>
> The server Controller should receive any packets from any addresses, because
> it listens as *:9090. The client controller receives packets only if a
> sender port number is 9090.
>
> Then, when DatagramSocketClient sends a packet to port 9090 of the local machine,
> I think client controller should receive the packet, because the sender port
> number is 9090.
>
>> If not, I thought it could be a problem because you had expected that only one server would receive the client(like DatagramSocketClient)'s packet.
>>
>> I would like to know your problem more clearly. :-)
>
> If you are not clear about what I said, please let me know it.
>
>> Please advice me.
>
> Thank you for your investigation.
>
> Minoru
>
>> Thanks.
>>
>> --
>> Bongjae Chang
>>
>>
>> ----- Original Message -----
>> From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
>> To: <dev_at_grizzly.dev.java.net>
>> Sent: Friday, June 12, 2009 11:32 AM
>> Subject: Re: Strange behavior of Grizzly
>>
>>
>> > Hi Bongjae,
>> >
>> >
>> > I tested your program. I modified only DatagramSocketClient part as I mentioned
>> > before. I tested your program on RHEL4, becuase I doubt Windows platform.
>> > The result was always like
>> >
>> > Wait for 2000(ms)
>> > current thread: Thread[server-WorkerThread(0),5,Grizzly], Request: hello world-1
>> > current thread: Thread[server-WorkerThread(5),5,Grizzly], Request: hello world-2
>> > current thread: Thread[server-WorkerThread(6),5,Grizzly], Request: hello world-3
>> > current thread: Thread[server-WorkerThread(7),5,Grizzly], Request: hello world-4
>> > current thread: Thread[server-WorkerThread(8),5,Grizzly], Request: hello world-5
>> > current thread: Thread[server-WorkerThread(9),5,Grizzly], Request: hello world-6
>> > current thread: Thread[server-WorkerThread(10),5,Grizzly], Request: hello world-7
>> > ###Binding duplicated socket again..###
>> > current thread: Thread[client-WorkerThread(6),5,Grizzly], Request: hello world-8
>> > current thread: Thread[client-WorkerThread(7),5,Grizzly], Request: hello world-9
>> > current thread: Thread[client-WorkerThread(8),5,Grizzly], Request: hello world-10
>> > :
>> >
>> > and this was exactly same as what I expected. During the test, I monitored
>> > by netstat command. Here is the snippet.
>> >
>> > Proto Recv-Q Send-Q Local Address Foreign Address State
>> > udp 0 0 rx200-3:9090 rx200-3:9090 ESTABLISHED
>> > udp 0 0 *:9090 *:*
>> > udp 0 0 rx200-3:9090 *:*
>> >
>> >
>> > The first line is a socket that is created by ConnectorHandler.connect.
>> > The second line is a socket that is created by DatagramSocketClient class.
>> > The third line is a socket that is created by grizzly controller (server part).
>> >
>> > Everything is OK for me.
>> >
>> > I tested your program on Windows, and sometimes the result was as same as Linux,
>> > but sometimes the result was
>> >
>> > Wait for 2000(ms)
>> > current thread: Thread[server-WorkerThread(1),5,Grizzly], Request: hello world-1
>> > current thread: Thread[server-WorkerThread(3),5,Grizzly], Request: hello world-2
>> > current thread: Thread[server-WorkerThread(4),5,Grizzly], Request: hello world-3
>> > current thread: Thread[server-WorkerThread(5),5,Grizzly], Request: hello world-4
>> > current thread: Thread[server-WorkerThread(6),5,Grizzly], Request: hello world-5
>> > current thread: Thread[server-WorkerThread(7),5,Grizzly], Request: hello world-6
>> > current thread: Thread[server-WorkerThread(8),5,Grizzly], Request: hello world-7
>> > ###Binding duplicated socket again..###
>> > current thread: Thread[server-WorkerThread(9),5,Grizzly], Request: hello world-8
>> > current thread: Thread[server-WorkerThread(10),5,Grizzly], Request: hello world-9
>> > current thread: Thread[server-WorkerThread(11),5,Grizzly], Request: hello world-10
>> > :
>> >
>> > This is a problem (at least for me).
>> >
>> > 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
>> >
>> >
>> >
>> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
>