Passive users connecting to Passive users

[Wolfbane]

I wanted to add this officially as a feature request, although I have mentioned this in the testhub and already got some feedback.

I really hope to have support for passive users connecting to other passive users without requiring configuration from the user.
As I understand it, this IS possible, but a tall order... Still, I think a feature such as this would vastly improve the usability of the Hubsoft, and also put it way ahead of all other hubsofts.

I'd like to discuss it further, and FlipFlop linked me some good papers on the topic but I seem to have lost the chatlog of that..

[FlipFlop™]

Here are the links discussing tcp and udp hole punching:

http://reports-archive.adm.cs.cmu.edu/anon/isri2005/CMU-ISRI-05-104.pdf
http://www.scs.stanford.edu/08sp-cs144/notes/l8.pdf
http://nutss.gforge.cis.cornell.edu/

This is not something that can be accomplished with a hubsoft alone, the client does a part of this technique, for example: it needs to tell the server it's own local IP address/port.

Other than that, i think it will need full access to the TCP or UDP protocol which is not entirely possible with any current lua socket-libs as far as i know.

Any practical ideas or discussion about how this could be make to work are very welcome ofcourse.

[Delion]

AUT0 ADC extension?

[FlipFlop™]

I would love an AUTO ADC extension, as soon as i find out what it is...

Got more info?

[Delion]

the 'AUT0' extension (network connection auto detection extension).
Rationale: Detect if client is capable of initiating active connections.

After logging in:

Client -> 'HCHK 12345 ABCD'.

Server sends a UDP packet containing token to the client's IP address at the given port as shown in the INF message.

Server -> 'ICHK ABCD'

The server should send it from a UDP socket bound to the same port as the TCP server, which means the server will
have to listen to both TCP and UDP.

If client receives the packet, it knows it can receive UDP connections, and will advertise it in the INF message as
a supported feature.

If the client does not receive any UDP packets within a few seconds, it MAY try to reconfigure the router using
UPnP/ZeroConf, and issue a HCHK command to the server again.

If the client still doesn't receive any UDP packets, hole punching can be tried.
The server will send a UDP packet to the hub (using the port of the TCP server), and reissue the HCHK command.
The UDP packet SHOULD be echoed by the hub.
This UDP packet should contain simply 'HECH {cid} {token}' (Hub echo).

The hub should send a packet containing the token back:
'IECH {token} {host:port}', aswell as the same message via TCP.

If the client receives the message via UDP, it should now be able to determine the type of NAT.
If the client receives the message via TCP only it knows it has a firewall blocking icomming communication.
If the client does not receive the message, it should assume a firewall is blocking all UDP communication,
and resume in passive mode.

Requirements:
'AUT0' in the extensions message (SUP) for client and hub.
Server will also listen to UDP messages on the same port as the TCP port.

The server MUST now respond to the 'HCHK' command via TCP
The server MUST now respond to the 'HECH' command via UDP.

The client will always initiate communication.

-------------------------------------------------------------------------------

Syntax: HCHK {port} {token}
- port is a 16-bit port number where the client is listening for packets.
- token is 4 bytes base32 encoded data specified by the client.

Example:
Client: 'HCHK 1511 BACD' (tcp)
Server: 'ICHK BACD' (udp)

-------------------------------------------------------------------------------

Syntax: HECH {cid} {token}
- cid is the client ID.
- token is 4 bytes base32 encoded data specified by the client.

Example:
Client: 'HECH 3NGFVJUDBRHX2CYRJGQ5HACRDM5CTNLGZ36M64I BACD' (udp)
Server: 'IECH BACD 192.168.0.1:1512' (udp)
Server: 'IECH BACD 192.168.0.1:1512' (tcp)

Security considerations:
The hub must verify that IP address where the HECH command originated from
matches the IP address where the user with the given CID is connected from.
If the CID and IP does not match, or the CID is not used the hub MUST ignore
the request.

It's from uHub documentation.

[en_dator]

I dont see that extension anywhere on adc or adcportal so doesnt look like it even made its way into a proposal?

Note that you forgot to include the beginning of the file

Code: [Select]

ADC protocol extensions supported:

STATUS: **** Not yet implemented.

the 'AUT0' extension (network connection auto detection extension).
Rationale: Detect if client is capable of initiating active connections.
Link http://github.com/janvidar/uhub/blob/master/doc/extensions.txt

I like the idea though, it could be one step closer to letting the client auto config itself with the correct network setup

[FlipFlop™]

Looks very interesting..

But: STATUS: **** Not yet implemented.

Is that outdated, or is this concept working already?
If it's working, then it won't be a problem implementing this. There's hardly any added functionality needed, except for the listening and sending on UDP.

Please let me know if this is working already, i'll be happy to add this functionality after beta-release.

[Delion]

It seems to be working on uHub.

[FlipFlop™]

Connecting passive-passive for NMDC has been implemented using NAT traversal by BigMuscle. The next FlexHub update will allow the traffic needed to support this.

New Strong++ based clients will then be able to connect passive-passive in FlexHub.

[Hamachi]

Nice one