4.33 not showing the right connection type (P2P/CS)
-
Morning gentlemen,
on our first large squadron flight with 4.33 i saw that the connection type in the clientlist is not correct. I saw that several clients connected with wrong ports (they have IPv6 connections) but were listed as P2P ….
-
:neutral:
-
A little detail from a developer to better help your understanding:
P2P means peer-to-peer and CS means client-server and these terms refer to the means by which a particular player’s session is connected to the rest of the game. Here’s what the code is looking at to decide whether to label the connection with one or the other:
Since the supplied portFirst and the actual port do not match, the client’s NAT rerouted the connection, and the actual port may not have proper forwarding. This connection is dubious. The host can allow these clients into the game and they may require data forwarding (extra load on host) or the host can disconnect these clients.
P2P is the desirable state. The network code is tuned for and works best with that kind of topology. A lot (but not all) of this has to do with smooth multiplayer experience by ensuring that the most latency-sensitive traffic goes via the shortest route between players (i.e. direct); think about position updates as the canonical example.
CS is what people mean when they talk about “dubious” connections in the F4 BMS world. The code has tried to make a direct connection between a player with a “CS” label on their connection and for some reason been unable to do so. Thus, it has fallen back to sending everything via the server to all other client sessions; i.e. every position update will take two hops to reach other players instead of only one (well, with the exception of a player who’s session is the host that is ;)). The fallback may work much of the time. However, if there’s any question about network bandwidth or excess of latency in some of the host to client connections, then allowing “dubious” connections can mess up a network game a little or a lot depending on degree. As such, a wise host probably disables the CS/dubious connection type by setting g_bHostAllowsDubiousConnections false in the config file and tells any player who can’t connect: “get a decent router with halfway decent NAT implementation or a direct internet connection!”.
-
Sorry, i should have written more details g
As server admin of our squadron i’m pretty much aware of the port forwarding / dubious connection etc. things. I have also detailed informations of the internet connections and port forwardings of our squad members.
We have several members (5-6) with IPv6 connections, as they get only a “virtual” IPv4 their port forwarding will never be right. These days it’s very hard for german users to get an internet connection with true IPv4, one of they main reason we desperatly wait for IPv6 support of BMS ….
Yesterday we had our first full scale 4.33 online test with 27 pilots. I monitored the whole test on our dedicated BMS server, ALL pilots were signed as P2P, also the ones i definitivly know they have dubios connections! Some of the others saw one or two connecting as CS, i for myself saw no one as CS, not on the server nor on my machine.
This is what implies that the labeling of the clients isn’t working correct.
-
Paraphrasing the same developer:
If “CS” is seen by anyone against the name of a remote player, that simply means that the local game copy wasn’t able to make a connection direct to the game copy on that remote player’s system. The “why” of that could be down to a variety of reasons, some of which are definitely beyond the ability of the code (at least in present form) to cope with and work around.
In the scenario above, it could be that the NAT implementation in the affected routers is fighting over port remapping or that the routes between the affected computers were shaky enough at connection start time that timeouts made it looks like direct connection was not working. If the results for those PCs are consistent every time they try to connect to a game then I’d suspect the former more than the latter; and vice versa. Putting Wireshark on the job might be more illuminating.
-
The “problem”, if it is one, is not that P2P connections are shown as CS. It’s more that CS connections are shown as P2P when it’s 100% clear there is no P2P connection is possible.
In 4.33 there are more informations about the client connections, also there connection port. This few clients have shown wrong ports, e.g. 42965 instead of 2935. So they should have been labeled as CS regardless of their good connection data.
Sure, it isn’t a big problem and no showstopper. For me it means i will still make connection test with debug-mode as the raknet log is reliable and the P2P/CS label isn’t.
