Hi Minoru,
I think that it is not possible in current Grizzly because Grizzly opens new channel when the client tries to connect the remote.
Then Grizzly has two channel, first is a server channel and second is a client channel, at this time.
I met a similar issue like your problem on TCP. The diffrence is that BindException was occurred when client tried to bind server's socket address which already had been bound.
So I didn't use local binding in client side.
But I think that it is also better that Grizzly can provide a client with the way of being able to use server's channel which already has been created.
Other devs may be able to know a good idea or another solution about this.
Let's wait for another opinions. :-)
Thanks.
--
Bongjae Chang
----- Original Message -----
From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
To: <dev_at_grizzly.dev.java.net>
Sent: Wednesday, June 03, 2009 12:21 PM
Subject: Re: Strange behavior of Grizzly
> Hi Bongjae,
>
>
> I tested your proposal, and it worked fine. During the test,
> I monitored port status by using netstat command. The result was as follows.
>
> [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 304 0 rx200-4:5060 *:*
> udp 0 0 *:5061 *:*
> udp 0 0 *:5062 *:*
> udp 0 0 rx200-4:54368 rx200-4:5061 ESTABLISHED
> udp 0 0 rx200-4:54369 rx200-4:5062 ESTABLISHED
>
>
> I want to use the send port as 5060, not 54369 or 54368.
> Is it possible to do that in grizzly?
>
>
> 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>
>
>