Open jerry-wolf opened 7 years ago
Why is it necessary to send different port to the tracker and bind an another on the local machine? If you want to use different port, then you can use that on local machine.
Port mapping is up to NAT gateway. The gateway create a random port mapping that has different port number, sometimes we can't control it (Like carrier-grade NAT). See: https://en.wikipedia.org/wiki/Network_address_translation#Methods_of_translation Full-cone NAT: If client below NAT send a request to a host which opened a port, the full-cone NAT gateway will assign a port mapping about internal_IP:internal_port(the port which the client send a request) <-> external port(randomly assigned). We can't set a port mapping without administrator permission. For home router, the methods of translation is usually (address)-restricted-cone NAT. It has more restriction, but we can set a port mapping manually or automation (via UPnP). So I think penetrate carrier-grade NAT and home router and open a port is still feasible.
And how do we know the randomly assigned port number?
For some gateway, we can open a port by Port Control Protocol, but it's not all gateway be supported.
A client connect to a port checker, then the port checker can get the external IP and external port of the client with data, address = socket.recvfrom(bufsize[, flags])
, then the port checker echo back to the client.
Perhaps we can depend STUN.
It's centralized, but I think that add a plugins to make every peers which can open a port is feasible.
But I'm not sure whether it's TCP-compatible.
The port checker can't get your external port as it not used in the connecting process (and you can have many of them), only your external ip.
It could be possible to add nat-pmp function for port opening, but I think upnp is more supported. I just tried https://pypi.python.org/pypi/NAT-PMP/1.0.1 and it's not working with my router.
I'm afraid that you did not understand what I meant. Not all NAT gateway allow standard user create a explicit port forward rule, but we can create a implicitly port forward rule using full-cone NAT gateway's feature.
I agree with @l5h5t7
I don't have access enviroment like this, so it would be hard to develop for it.
It need's a lot of work. Maybe better spend this time developing IPv6 support? https://github.com/HelloZeroNet/ZeroNet/issues/148
It need's a lot of work. Maybe better spend this time developing IPv6 support? #148
Yes and no. Both things are required because I don't think that IPv6 support will be high enough everywhere to solve the issue.
Due to the lack of IPv4 address, more and more ISP have been deployed carrier-grade NAT. So less connectability for these users. Tor network can improve the connectability for these users, but it has many issues for the users who needn't anonymity:
IPv6 is the ultimate solution, but it still have a long way to go. (15% supportive in the whole world, and only 1% supportive in China)
Full-cone NAT is most used in carrier-grade NAT and easy to penetrate. We need do these thing for support port opening supports below full-cone NAT
Separated port number is also useful in the environment: