![[gb]](/mwf/flags/gb.png "United Kingdom")
> UPnP and enhanced Holepunching should help through most routers.
UPnP is meant for discovering media services, not fiddling with security-relevant settings of your router. I'm not really comfortable with telling people to enable it.
And how would you "enhance" hole-punching?
![[de]](/mwf/flags/de.png "Germany")
>I'm not really comfortable with telling people to enable it.
Neither am I (and I already stated that), but if it's not enabled, you have to go to the router config, and you can do the forwarding.
>And how would you "enhance" hole-punching?
Make it two-sided and designated. The current system punches on the port to an ip which does not belong to the host, and only from the host. I have tested punching from both sides with the right destination ip and it opened much more routers than the current system. I've already tried implementing that once, but I just don't see through the network code...
You hope that your Router is nice and assigns all outgoing connections from the same ip and port the same external port. The netpuncher server will receive things with that sourceport. If the router isn't that nice (or lazy, that's viewpoint-dependant), you won't get holepunching to work, no matter what you try.
Clonk already blindly tries to connect to IP:Port - from both sides. Shouldn't that have that effect already?
For clients, yep. (Apart from that the external port is not checked, but in my test, most of the routers didn't change it if there was only one internal machine operating on that port) But the goal is to make the server make an attempt to connect to the client so the server's router gets punched into that direction.
The master server? Or the host? Do you mean for the initial connection? How should the host know about the client's connection attempt then?
> How should the host know about the client's connection attempt then?
There has to be an intermediary server... Remember the netpuncher?
So you want the host to maintain a permanent connection to a central server that notifies it when there's a client that wants to connect to it? The netpuncher just reflected pings, this might be a bit more involved.
Yep, that's exactly it. But if that's a fallback to UPnP and the last option before not being able to host, I'd accept it.
As you describe it, it would help in a very specific scenario only - that both are behind a router each that happens to re-use the port number on the outside. It already wouldn't help if, say, the client router reassigned ports.
Actually - it would also help if the client in question had set up its forwarding properly. That would probably be the more noticeable effect. Still not sure I'm a fan of the idea though.
Actually - it would also help if the client in question had set up its forwarding properly. That would probably be the more noticeable effect. Still not sure I'm a fan of the idea though.
>that both are behind a router each that happens to re-use the port number on the outside.
One that reuses is enough. And it doesn't have to re-use the exact port, just the external port for the internal port and ip. The external port then has to be changed for the ms-reference.
Why? We are working under the assumption here that the router will discard packets of port numbers it hasn't seen an outgoing packet yet for. So if one side reassigns the port number, the other side has no way of discovering this - so packets in neither direction will reach their goal.
>the other side has no way of discovering this - so packets in neither direction will reach their goal.
Please define reassign. I've observed that the external source port is often stable for one internal ip and source source port combination. If the router chooses a new external source port for every connection, hole punching can't work.
Anyway, my method works in more cases than the current one does.
Hm, you are right in that if we used the same port for central server communication as we use for game data, the central server would be able to know the reassigned port address. That's really dirty business though. My head aches even trying to think of a good interface for that. It would have to be buried somewhere deep in C4NetIOUDP, that's for sure.
> I've already tried implementing that once, but I just don't see through the network code...
Btw - the starting point for this as well as pre-lobby pings would be to exploit that C4NetIOUDP is already answering to pings without creating a connection (code).
So it should be possible (if a bit naughty) to build a pinger on top of C4NetIOSimpleUDP that just uses C4NetIOUDP's format for a ping, but never follows it up with a connection. The code would probably end up looking very similar to C4Network2DiscoverClient. Minus all the multicast stuff.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
