Hi guys,
we some time ago we had discussion with Radim Kolar regarding Grizzly
UDP [1], and here is interesting part Radim mentioned:
"statefull firewalls can do something like this and it can be possibly
simulated in Java:Code something like ACCEPT for UDP:
After receiving UDP packet on server socket, check own database of
client ip/client port combos. If client ip/port combo is found in
database it is probably
safe to ignore packet because it should arrive on second channel too.
If no known client is found, create new UDP channel and bind it to
server ip,port (with addr reuse) and then connect() it to client ip/
port. you will get
new SelectionKey - unique to client
This is a bit OS dependent because UDP packet from client can be
received by both channels or just by newly created channel. Modern
OSes should forward received UDP packet just to new channel but it
needs some testing.
"
So, basically setReuseAddress(...) behavior could me even more
interesting, but really depends on OS.
WBR,
Alexey.
[1]
http://www.nabble.com/UDP-connections-supported--td13364353.html#a13397920
On Jun 12, 2009, at 12:40 , Bongjae Chang wrote:
> Hi Jeanfrancois,
>
> I have tried to test with true/false about Controller#setReuseAddress.
>
> I could see the following result.
>
> On Windows:
> [true]
> Sometimes the receiver is switched, sometimes the receiver is
> preserved, so we can't detemine what channel will receive the packet.
> And binding policy is more flexible than Linux.
> For examples, assuming that x.x.x.x is a specific address of local
> interface,
> "0.0.0.0:9090" like any address without setReuseAddress set to be
> true can be also bound after "x.x.x.x:9090" has been already bound
> with setReuseAddress set to be true.
>
> [false]
> We are never able to bind the same address because of BindException
> regardless of Blocking IO and NIO.
>
>
> On Linux:
> [true]
> The receiver is always switched. It seems that last bound channel
> will be used and updated.
> "0.0.0.0:9090" like any address without setReuseAddress set to be
> true can't be bound after "x.x.x.x:9090" has been already bound with
> setReuseAddress set to be true.
> But "0.0.0.0:9090" can be bound if the socket for any address set to
> be true about setReuseAddress.
>
> [false]
> We are never able to bind the same address because of BindException
> regardless of Blocking IO and NIO.
>
> So, if I set setReuseAddress to be false about Controller, the
> receiver will be preserved because another trials which try to bind
> the same address will be failed with BindException regardless of
> platform.
>
> I am worrying if you are satisfied with this result.
>
> If you need more tests or are anxious to know another test, please
> let me know what to do.
>
> Thanks.
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: "Jeanfrancois Arcand" <Jeanfrancois.Arcand_at_Sun.COM>
> To: <dev_at_grizzly.dev.java.net>
> Sent: Friday, June 12, 2009 12:09 PM
> Subject: Re: Strange behavior of Grizzly
>
>
>> Salut,
>>
>> jumping....on win32. setReuseAdress should be set to false as it
>> gives
>> unexpected result. Sorry I might say something stupid, but have you
>> try
>> with true/fasle to see if that make a difference?
>>
>> Thanks!
>>
>> -- Jeanfrancois
>>
>> Bongjae Chang wrote:
>>> Hi Minoru,
>>>
>>> I have a question and maybe I didn't understand your words clearly.
>>>
>>> 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?
>>>
>>> I thought that DatagramSocketClient should send the packet to the
>>> same server.
>>>
>>> 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. :-)
>>>
>>> Please advice me.
>>>
>>> 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
>>
>>
>>
>>