Closed fversnel closed 8 years ago
I'm sorry to be a bit of offtopic here, but can have you ever met a problem when after a NAT punchthrough an unconnected message is successefully delivered yet a .Connect()
message is completely ignored? (IncomingMessageType is enabled). I wireshark'ed and found out that the message is kinda of 'sent' by the client and 'received' by the server but somehow ignored by the lidgren.network.
I've never observed behavior like that. Can you reproduce this somehow?
It is reproduced in a very strange manner. I doubt you can repro this in the correct way:
There is a computer A behind NAT. There is also a computer B behind router with correct port forwarding. A Lidgren server is running on the B. A client is running on A. A master server (C) makes a NAT punchthrough (not neccessary, but still) and after that A sends an unconnected message to B and that message always delivers. However if A sends Connect()
message, it never delivers!
What is more interesting is when we switch A and B places with each other, everything works fine!
So does this still happen when you run Lidgren with this patch included? Because this patch should make sure unconnected messages can be sent in both ways.
On Sat, Feb 20, 2016 at 12:46 PM AgentFire notifications@github.com wrote:
It is reproduced in a very strange manner. I doubt you can repro this in the correct way:
There is a computer A behind NAT. There is also a computer B behind router with correct port forwarding. A Lidgren server is running on the B. A client is running on A. A master server (C) makes a NAT punchthrough (not neccessary, but still) and after that A sends an unconnected message to B and that message always delivers. However if A sends 'Connect()` message, it never delivers!
What is more interesting is when we switch A and B places with each other, everything works fine!
— Reply to this email directly or view it on GitHub https://github.com/lidgren/lidgren-network-gen3/pull/63#issuecomment-186577158 .
@fversnel no change.
And so I still get "No response from remote host" when connecting from A to B. Along with unconnected messages processed with 100% success. When connecting from B to A everything is ok. When connecting from B to B or from A to A everything is ok too.
Right, just to verify: the NAT punch worked so A has received a message from B and B has received a message from A? In that case we can narrow it down to the connection making process. You'd have to debug how Lidgren attempts to make connections.
That's what I am doing now. I'll create a pull request as soon as I finish.
It turns out that was completely my bad - was trying to connect from different port which (as I wrongly thought an opposite) was not NAT-punched even if its neighbour was.
However, before the events described above I did indeed met the problem of not accessing (unconnected messages included) the NAT-punched target which I do belive your patch fixes as I have yet to met that problem again after installing it onto my copy of the library.
@lidgren I can confirm now - this patch definitely improves the situation when sometimes NAT punch doesn't work out.
@lidgren is anything else needed from us from you to merge? <3
Thanks :)
No, thank you :-)
Does the NAT punch of this branch work on 4G ?
I think NAT punching over 4G is a bit more involved than what Lidgren currently does. See: https://stackoverflow.com/questions/10291759/upnp-nat-traversal-for-3g-4g-wireless-data-connection-on-android
You could always try and see if it works though.
Thanks :)
Clients that request an introduction now first request a confirmation from the server to make sure unconnected messages can be sent in both directions before attempting to make a connection. Similarly the server automatically sends a confirmation to the client to reduce the possiblity that either one of the endpoints has issues with sending messages to the other.