async_load[? "port"] does not return useful information in TCP

[PNelly]

Morning guys,

I'm building a hobby networking project and I've discovered some behavior that doesn't make sense to me.

When a server receives a network_type_data event, the documentation states that async_load[? "port"] will return "the port associated with the IP address".

When using UDP, this works as expected, returning the port number in use on the origin machine. However, when using TCP, regardless of connect, disconnect, or data events, querying async_load[? "port"] will return the port number the machine receiving data.

First, I can't see how this is useful in any way. We already know the local port number from calling network_create_socket_ext() or network_create_server().

Second, it's well known that it's easy enough perform UDP hole punching with GMS, but I wanted to experiment with NAT traversal using TCP. If there's no way to get the origin port number of data/connections received by a server, then it's simply not possible.

So, am I correct in my assessment that this doesn't seem right? And second, does anyone know of a way that I could get the origin port number of data received by a server in TCP?

Cheers

 

[FrostyCat]

You seem right on both counts. The only way I could think of is to write the handshake server in another language and try to get the local server socket to connect to that for an answer. No guarantees on that working since the documented functionality is for client sockets to initiate the connection.

 

[PNelly]

Glad you agree. Bug report filed.

This is the best source I've found on the hole punching, whether TCP or UDP: http://www.bford.info/pub/net/p2pnat/index.html

TCP hole punch may remain a pipe dream as the article suggests that you have to bind multiple sockets to the same port to facilitate the process, which I don't believe GM will allow.