I am using the LLAPI to have a somewhat peer 2 peer network architecture, which means I have the host tell every player all the connections they should connect to.
When a player joins, the host tells the players in the game to connect to that new player, and the host also tells the new player to connect to all the players in the game.
So now we have both connections trying to start a connection with each other.
The issue is that unity seems to accept connections even though we are already connected to the same ip and port.
Is this intended?
If we were to get the ability to first check connection requests before accepting them, I could probably do the check myself, but we dont have that ability at the moment, so am I just stuck needing to disconnect one of the detected duplicate connections?
So your duplicate connections are coming from, as an example, Player3 joins an existing game with Player1 and Player2. Both Player1 and Player2 make connection to Player3, while Player3 at the same time makes connection to Player1 and Player2.
Assuming all are successful, there are duplicate connections between Player 3 and both other players, but they aren’t technically “to the same ip and port” because in each case Player3 is host of a duplicate connection and also the client of a duplicate connection. In any duplicate where the player is the client of the connection the client port should be a randomly chosen port, only on the server side of the connection should it be a fixed port number (that’s standard TCP/IP stuff, that I’m making an assumption Unity is not deviating from, but I could be wrong).
Why in this scenario aren’t you only having Player3 make the initial connections when joining? That would ensure no duplicates. You could wait a predetermined timeout and if connection from Player3 to either Player1 or Player2 has not been established, Player3 would no longer attempt connection itself and any player missing connection to Player3 would attempt to establish connection to Player3. Doing this should ensure duplicates either never occur or are at least rare.
Lets assume the layout is Player1-Host, Player2 and Player3
-Player1-Host creates server
-Player2 joins Player1-Host
-Player3 joins Player1-Host
At this point, Player2 and Player3 have no idea about eachother. They only know Player1-Host since Player1-Host has a static IP and port. Player2 and Player3 could be any IP and any port.
-Player1-Host tells Player3 to connect to Player2
-Player1-Host tells Player2 to connect to Player3
-Player2 detects connection request from Player3 and accepts
At this point Player2 and Player3 have detected a successful connection
-Player3 detects connection request from Player2 and accepts
At this point Player3 and Player2 have detected yet another successful connection
There is now 2 connections between Player2 and Player3
Player1-Host, Player2 and Player3 are all on a separate port, however, in the example I gave above, Player2 and Player3 would have made 2 connections on the same ports.
In other words, Lets assume Player3-Host is port 7777 Player2 is port 8888 and Player3 is port 9999.
At the end of the connections in my example above…
-Player1-Host would have a connection to Player2 on port 8888, and Player3 on port 9999
-Player2 would have a connection to Player1-Host on port 7777, to Player3 on port 9999, and yet another to Player3 on port 9999.
-Player3 would have a connection to Player1-Host on port 7777, to Player2 on port 8888, and yet another to Player2 on port 8888.
I guess my reasoning for that would be having this act as some sort of NAT Punchthrough, but perhaps I am wrong on that? For localhost it would have no point, as well as for when using Steams lobby system since steam handles the NAT Punchthrough for us.
Either way, it seems like something that we should at least be given the ability to avoid. Hopefully they add the ability to ignore/refuse connection requests before they are successfully made so that I can just prevent this myself. However, if duplicate connections wasnt intended, then hopefully it can get fixed.