Semantics of setReuseAddress(true) - or its possible to share outgoing/incomingport between connector/acceptor

Hi list

Ok, that was a lengthy subject, but it says more or less what I need to
know. In my open-source pet project
(http://sourceforge.net/projects/nataware/) I'm trying to implement a
mechanism to push through NAT devices. There I need to "punch" a hole in
the NAT with a connection from inside to outside the local subnet. Then
the other side should be able to establish a connection with the same
IP:Port combination from outside. To make this work, a acceptor has to
be listening on the same port for incoming connections as the outgoing
connection uses locally. But this seems not to work. If I set the
acceptor first to listen on the port, the outgoing connector cannot
establish the connection. If I start the outgoing connection first and
then start to listen on the same local port, it never receives a
message. I set the acceptor to reuse the address and also on the session
of the connector...

Here's an example
1) local node starts connection to remote node: 192.168.1:51234 ->
199.12.12.22:51222 (public NAT address)-> 211.22.22.33:8888
2) local node starts listening on 51234
3) remote node starts a connection from 211.22.22.33:8888->
199.12.12.22:51222 -> 192.168.1:51234
For simplicity my tests forget about the NAT device so it's all about
local ports:
1) localhost:51234 -> localhost:8888
2) listening on localhost:51234
3) localhost:8888->localhost:51234
And: it doesn't work

What's the difference to set the setReuseAddress on the acceptor vs
setting setReuseAddress on the session config?

Thank you for clearing this up:-)
Dani

Hi,

>> 1) localhost:51234 -> localhost:8888
>> 2) listening on localhost:51234
>> 3) localhost:8888->localhost:51234

it seems like what you're doing in (3) is to try and establish a second
connection over the same (IP:Port, IP:Port) pair, which is not allowed
actually, since a socket connection is uniquely identified by a (IP:Port,
IP:Port) pair.

Please correct me if i'm wrong...



Regards,
Edwin



--- Dani Eichhorn <dani.eichhorn-eR1wvSbX9og@public.gmane.org> wrote:

> Hi list
>
> Ok, that was a lengthy subject, but it says more or less what I need to
> know. In my open-source pet project
> (http://sourceforge.net/projects/nataware/) I'm trying to implement a
> mechanism to push through NAT devices. There I need to "punch" a hole in
> the NAT with a connection from inside to outside the local subnet. Then
> the other side should be able to establish a connection with the same
> IP:Port combination from outside. To make this work, a acceptor has to
> be listening on the same port for incoming connections as the outgoing
> connection uses locally. But this seems not to work. If I set the
> acceptor first to listen on the port, the outgoing connector cannot
> establish the connection. If I start the outgoing connection first and
> then start to listen on the same local port, it never receives a
> message. I set the acceptor to reuse the address and also on the session
> of the connector...
>
> Here's an example
> 1) local node starts connection to remote node: 192.168.1:51234 ->
> 199.12.12.22:51222 (public NAT address)-> 211.22.22.33:8888
> 2) local node starts listening on 51234
> 3) remote node starts a connection from 211.22.22.33:8888->
> 199.12.12.22:51222 -> 192.168.1:51234
> For simplicity my tests forget about the NAT device so it's all about
> local ports:
> 1) localhost:51234 -> localhost:8888
> 2) listening on localhost:51234
> 3) localhost:8888->localhost:51234
> And: it doesn't work
>
> What's the difference to set the setReuseAddress on the acceptor vs
> setting setReuseAddress on the session config?



Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/sg/

Hi Edwin
> Hi,
>
>
>>> 1) localhost:51234 -> localhost:8888
>>> 2) listening on localhost:51234
>>> 3) localhost:8888->localhost:51234
>>>
>
> it seems like what you're doing in (3) is to try and establish a second
> connection over the same (IP:Port, IP:Port) pair, which is not allowed
> actually, since a socket connection is uniquely identified by a (IP:Port,
> IP:Port) pair.
>
That's exactly what I was trying to do. And your answer is what I was
afraid to hear;-). So I guess I will have to do it another way. Maybe
the upcoming meta transport functionality will help me with it..
Actually, what I was trying before and what worked is to tunnel all
incoming data through the connection established in 1). The only problem
is, that I will run into problems if multiple users will try to use the
tunnel at the same time. Do you know, what the status of the meta
transport support is in MINA?

Dani

Hi,

sorry, i'm not too familiar with the meta transport mechanism.

but your original idea does sound workable. in fact, it's kind of similar to
the passive FTP mechanism. i don't quite understand the difficulty you ran into
though. why would multiple users try to use the same established connection?



Regards,
Edwin



--- Dani Eichhorn <dani.eichhorn-eR1wvSbX9og@public.gmane.org> wrote:

> That's exactly what I was trying to do. And your answer is what I was
> afraid to hear;-). So I guess I will have to do it another way. Maybe
> the upcoming meta transport functionality will help me with it..
> Actually, what I was trying before and what worked is to tunnel all
> incoming data through the connection established in 1). The only problem
> is, that I will run into problems if multiple users will try to use the
> tunnel at the same time. Do you know, what the status of the meta
> transport support is in MINA?



Get your new Email address!
Grab the Email name you've always wanted before someone else does!
http://mail.promotions.yahoo.com/newdomains/sg/

The established connection is some kind of tunnel. Lets say we have a
scenario with four nodes: Alice is behind a NAT device, Bob is her proxy
or endpoint of the tunnel and is not behind a NAT. Carl needs to send a
message to Alice. Since it is not possible to reach Alice directly (she
doesn't use any port forwarding) he sends his message to the open
endpoint of the tunnel on Bobs computer. The message will be sent
through the tunnel. On Alices end of the tunnel a new connection gets
established to the local service consuming the message (e.g. web
service). If required, Alice can send a response back through the tunnel
to Carl . This works fine as long as not a 4th node called Dora wants to
use the tunnel at the same time as Carl. Where would the open end point
send a response to?
I don't know how the session could be multiplexed on Bobs node...

Carl->Bob relaying message->tunnel->Alices local service
Dora->Bob->tunnel->Alice
Response:
Alice->tunnel->Bob->?, Carl or Dora
The tunnel in the middle is just one connection with one session. How
could Bob multiplex the response from Alice to the right endpoint?

Dani

Edwin Lee wrote:
> Hi,
>
> sorry, i'm not too familiar with the meta transport mechanism.
>
> but your original idea does sound workable. in fact, it's kind of similar to
> the passive FTP mechanism. i don't quite understand the difficulty you ran into
> though. why would multiple users try to use the same established connection?
>
>
>
> Regards,
> Edwin
>
>
>
> --- Dani Eichhorn <dani.eichhorn-eR1wvSbX9og@public.gmane.org> wrote:
>
>
>> That's exactly what I was trying to do. And your answer is what I was
>> afraid to hear;-). So I guess I will have to do it another way. Maybe
>> the upcoming meta transport functionality will help me with it..
>> Actually, what I was trying before and what worked is to tunnel all
>> incoming data through the connection established in 1). The only problem
>> is, that I will run into problems if multiple users will try to use the
>> tunnel at the same time. Do you know, what the status of the meta
>> transport support is in MINA?
>>
>
>
>
> Get your new Email address!
> Grab the Email name you've always wanted before someone else does!
> http://mail.promotions.yahoo.com/newdomains/sg/
>
>

On Mon, Nov 10, 2008 at 7:18 PM, Dani Eichhorn <dani.eichhorn-eR1wvSbX9og@public.gmane.org> wrote:
> The established connection is some kind of tunnel. Lets say we have a
> scenario with four nodes: Alice is behind a NAT device, Bob is her proxy or
> endpoint of the tunnel and is not behind a NAT. Carl needs to send a message
> to Alice. Since it is not possible to reach Alice directly (she doesn't use
> any port forwarding) he sends his message to the open endpoint of the tunnel
> on Bobs computer. The message will be sent through the tunnel. On Alices end
> of the tunnel a new connection gets established to the local service
> consuming the message (e.g. web service). If required, Alice can send a
> response back through the tunnel to Carl . This works fine as long as not a
> 4th node called Dora wants to use the tunnel at the same time as Carl. Where
> would the open end point send a response to?
> I don't know how the session could be multiplexed on Bobs node...
>
> Carl->Bob relaying message->tunnel->Alices local service
> Dora->Bob->tunnel->Alice
> Response:
> Alice->tunnel->Bob->?, Carl or Dora
> The tunnel in the middle is just one connection with one session. How could
> Bob multiplex the response from Alice to the right endpoint?

Why do you want to write this?
Isn't this what ssh tunneling does?

shh support port forwarding/tunneling to arbitary iports.
Check out the docs for it.

> Why do you want to write this?
> Isn't this what ssh tunneling does?
>
> shh support port forwarding/tunneling to arbitary iports.
> Check out the docs for it.
>
You're right. You could say, what I'm trying to do is tunneling
comparable to SSH Tunnels. But I need to be able to control those
tunnels from my java library. The tunnel is more a tool than the purpose
of the library. In the end my library will be able to establish direct
connections between to PCs, both behind a NAT device. Using the library
you will be able to send huge amounts of data directly from one node to
the other and you could write applications that allow file exchange
between two nodes or allow video conferencing. In this cases you don't
want a third node to relay the data, you want the two participating
nodes to carry the burden. In this context the tunnels only serve for
message exchange, not as a transport vehicle for the big amount of data
(see my presentation at Jazoon'07:
http://jazoon.com/download/presentations/820.pdf if you're interested in
the details). In my diploma thesis some years ago I could prove that it
works, but now I'm rewriting the whole code to make it more useful.
If you know of any implementation of (SSH) tunneling using MINA please
let me know, then I can save the time to do it myself.

Dani

Hi,

ok, i see what you mean now. you're right that with this implementation, when
Bob receives a response from Alice he won't know who to forward it back to.

i can think of two (possibly naive) enhancements:

1. When Bob and Alice exchange data, include some information on who the
request originated from (i.e. either Carl or Dora).

2. Have multiple connections between Alice and Bob.
a. One main "communication channel".
b. Whenever a different party connects to Bob, Bob will make a request for a
new connection to Alice (via the existing "communication channel").
c. Alice will then initiate a new connection with Bob.
d. Bob maintains a 1-1 mapping of (connections between someone else (e.g. Carl
or Dora) and Bob) to (connections between Bob and Alice).

Just 2-cents worth...



--- Dani Eichhorn <dani.eichhorn-eR1wvSbX9og@public.gmane.org> wrote:

> The established connection is some kind of tunnel. Lets say we have a
> scenario with four nodes: Alice is behind a NAT device, Bob is her proxy
> or endpoint of the tunnel and is not behind a NAT. Carl needs to send a
> message to Alice. Since it is not possible to reach Alice directly (she
> doesn't use any port forwarding) he sends his message to the open
> endpoint of the tunnel on Bobs computer. The message will be sent
> through the tunnel. On Alices end of the tunnel a new connection gets
> established to the local service consuming the message (e.g. web
> service). If required, Alice can send a response back through the tunnel
> to Carl . This works fine as long as not a 4th node called Dora wants to
> use the tunnel at the same time as Carl. Where would the open end point
> send a response to?
> I don't know how the session could be multiplexed on Bobs node...
>
> Carl->Bob relaying message->tunnel->Alices local service
> Dora->Bob->tunnel->Alice
> Response:
> Alice->tunnel->Bob->?, Carl or Dora
> The tunnel in the middle is just one connection with one session. How
> could Bob multiplex the response from Alice to the right endpoint?



New Email addresses available on Yahoo!
Get the Email name you've always wanted on the new @ymail and @rocketmail.
Hurry before someone else does!
http://mail.promotions.yahoo.com/newdomains/sg/

Edwin Lee wrote:
> Hi,
>
> ok, i see what you mean now. you're right that with this implementation, when
> Bob receives a response from Alice he won't know who to forward it back to.
>
> i can think of two (possibly naive) enhancements:
>
> 1. When Bob and Alice exchange data, include some information on who the
> request originated from (i.e. either Carl or Dora).
>
Currently I copied some code of the proxy example and there the
forwarding happens in the messageReceived method of the proxy handler. I
could insert some kind of session identifier in front of the message and
the receiver could demultiplex and choose the proper session to forward
the data to, according to some bytes inthe beginning of the message. I
think that is also more or less what SSH Tunneling does: create a new
package and take the payload piggyback
> 2. Have multiple connections between Alice and Bob.
> a. One main "communication channel".
> b. Whenever a different party connects to Bob, Bob will make a request for a
> new connection to Alice (via the existing "communication channel").
> c. Alice will then initiate a new connection with Bob.
> d. Bob maintains a 1-1 mapping of (connections between someone else (e.g. Carl
> or Dora) and Bob) to (connections between Bob and Alice).
>
Might work too. The question is, which is the more stable/ reliable
approach... Hm, I guess I have to find out, if that meta transport idea
of Trustin would solve most of my problems for free, before inventing
the wheel again...