The Port Forwarding thread: Minimizing multiplayer connection issues
- Thread starter Viajero
- Start date
I set it up almost without thinking because I was using it before I got fiber service.
You wouldn't happen to be in Australia? If you are, you'll never get a lower ping no matter what service you have because there's no servers on the same continent.
Try turning it off. Port forwarding keeps a port open to allow incoming connections without prior invitation, which is unneccessary if you're not hosting a dedicated server. An outgoing packet of data will also open a port on the way out, so that the reply can actually get back to you (the entire internet only works because of this - otherwise, you'd request a web page and be unable to receive the data, for example). Our clients always send an outgoing communication first, so there is no reason to have a port open preemptively.
Port forwarding does sometimes hide or sidestep problems, but that's almost worse, because people who believe it fixes a problem will be unwilling to entertain the possibility that the connection problem that still exists is caused by (and therefore fixable on) their end of the equation. They will instead blame anything and everything else, and never actually try to adjust anything on their end, ensuring that the problem will always persist.
One very real issue that you might need to adjust is something called MTU (Maximum Transmission Unit) size - basically the largest packet of data that can traverse the network without having to be split into smaller packets (fragmentation). When a packet is not received on the other end (dropped), it has to be resent - if one fragment of a packet is dropped, the entire packet has to be resent (and re-fragmented, and all of those fragments have to make it or the whole process happens again). Because of this, fragmentation can exponentially increase the odds of dropped packets, which will increase latency and connection issues.
The other aspect of fragmentation is that each packet has, in addition to the data being sent, a header that is used to get that packet to its destination. When a packet is fragmented, each fragment will have a copy of the header, meaning more of your bandwidth is now dedicated to routing information and such, rather than to the actual data you need to send.
Here is Cloudflare's much better explanation of fragmentation and MTUs: What is MTU?
Here is a quick test you can do to see if the default MTU is too large:
Code:
ping -f -l 1472 google.comHopefully this infodump helps - let me know if anything needs clarification
Last edited:
That analogy only applies when the server is dedicated e.g. a web server.
Think about how it works with ED's peer-to-peer model - one side initiates by making an outgoing connection, but where is it going? To another peer which has no previous contact/existing connection with that IP and will simply drop any packets from it (unless there is a forwarding rule set up).
Correct - port forwarding in general only applies to situations involving a dedicated server. In the case of Elite, Frontier's servers have ports opened to receive connection requests from all of the clients. The server then tells the peers where to go from there, and that's how all of the peers know to send an outgoing packet (opening a port) every time it's needed.
Remember that Elite isn't a pure peer to peer system - there are still dedicated servers involved, but none of the players are hosting them
You've missed the point completely because you're focused only on the machine initiating the connection and not the one receiving.Correct - port forwarding in general only applies to situations involving a dedicated server. In the case of Elite, Frontier's servers have ports opened to receive connection requests from all of the clients. The server then tells the peers where to go from there, and that's how all of the peers know to send an outgoing packet (opening a port) every time it's needed.
Remember that Elite isn't a pure peer to peer system - there are still dedicated servers involved, but none of the players are hosting them
The peers need to be able to communicate directly with each other. It is impossible for them to both initiate a connection to each other at the same time - one of them will always be first - and may be unable to reach each other because the receiving router will not have a NAT entry associating the IP+port of the incoming packet with any local machine IP+port. This is why port forwarding needs to be active, so the router will unconditionally forward those packets to the right machine.
Except that they do initiate communication with each other simultaneously, when instructed to do so by the frontier server. The port forwarding is set up on the frontier server, because it is a dedicated server. Neither client is a dedicated server, so port forwarding is unneccessary at best, and could cause people to believe they've solved a problem when they haven't.
Essentially, the frontier server acts as an introducer, telling each of the clients how to reach the other. Both clients then begin sending UDP packets to each other, and while the first burst of packets might be rejected, it won't take long for each client to have established open ports due to their respective outgoing packets, allowing the incoming packets to get through, without holding a port open 24/7. It's a process sometimes called UDP hole punching, and it's a common technique used for peer to peer communication when there is a dedicated server that both clients can reach to do the initial introductions.
If port forwarding was required, I simply would not be able to connect - it isn't required, because it's not a neccessary part of the process. It is just a really popular myth among gamers that port forwarding makes things better, when in reality it might side step some issues some of the time (giving it the illusion of having fixed a problem). But there are many other situations where it does nothing to sidestep the problem, yet people set it up and then insist that any remaining problems are not on their end, because they're using port forwarding. The problem very well could still be on their end, and therefore unfixable by anyone else, but will never be addressed by the one person who could do so, because, again, they're under the incorrect assumption that port forwarding solves things and that they have no reason to try anything that actually might solve the problem.
Last edited:
Unless the clients somehow have their NICs (and routers) synchronized to the same clock, such a thing is impossible.
The server can't know which ports to direct each client to, because the router allocates outgoing ports (and creates a NAT table entry) as connections are attempted, based on the source IP+port and destination IP+port pair. There is no way for the local machine to communicate to the server in advance which port the router is going to assign.
Not all routers act the same - some are more insecure than others and will only associate an external port with an internal IP+port, rather an requiring a full external IP+port match. ED also falls back to using TURN if direct connections are unavailable.
They don't need to be synchronized - each client fires packets at the other, expecting the first few to get dropped. Those outgoing packets open a return path at each node they traverse, and when both clients have successfully opened a path all the way to their respective public-facing IP addresses, the next incoming packets to arrive will make it all the way to their intended recipient. Like I said, google "UDP hole punching" - it's not just a theory, it's a technique that has been used for decades at this point.
The local machines don't communicate which port they're assigned in advance - they communicate that info after the port has been assigned, via the packet headers, as is the norm in IP protocol. And since both clients know about and initially communicate with the server, that's the mutual connection point where the port assignement info is exchanged between clients. The server initially only needs each client to have established a connection with the server, through which it is able to send them replies without knowledge of which ports are used at each node along the return path.
Every single router that has ever been, assigns an external port for replies to come back through. They would be unable to hear replies, otherwise. They would, for example, send a request to a web server for a given webpage, and never receive the page data because there would be no path for the data to reach them. It's a fundamental component of the way IPv4 functions.
Regardless, port forwarding only does one thing - keeps a port on your router open. The intended purpose is to allow unsolicited incoming connections through, which is to say, connections that might come at any time without prior notice. Our game clients are never in a situation where a connection is unexpected, because the clients communicate with the servers from the moment they log on. The servers tell the clients where to send further communications so that they can establish the peer-to-peer communication. Any problem that it does manage to sidestep is a problem that still exists - and if it doesn't sidestep the problem and he only "solution" one knows about is port forwarding, the problem will persist and the user will insist that it's out of their hands, when it isn't.
Port forwarding is for servers. Period.
Ned is right.
IF the ED client does not have access to a Port Forward or UPNP active router, it wont be able to receive incoming connections (non-initiated locally in advance) from other ED clients
In which case it will be able only to connect to a session made available by an ED client that has working upnp or port forwarding
(OR to use FDev Turn servers to connect to sessions from other "closed" ED Clients with the added implied overhead)
That's not the fundamental component of the way IPV4 functions.
That's how NATTING works. The NAT performed by the router will know how to match the outgoing session with the response from the destination and will make sure that response reaches the initiator located behind the NAT. For that to happen, the client behind to the NAT Router needs to initiate the connection to the external party
But unless you create a specific reverse nat rule aka port forwarding (or UPNP), the router doing NAT will not allow an external IP to connect to a port exposed on the internal client
edited for clarity
IF the ED client does not have access to a Port Forward or UPNP active router, it wont be able to receive incoming connections (non-initiated locally in advance) from other ED clients
In which case it will be able only to connect to a session made available by an ED client that has working upnp or port forwarding
(OR to use FDev Turn servers to connect to sessions from other "closed" ED Clients with the added implied overhead)
That's not the fundamental component of the way IPV4 functions.
That's how NATTING works. The NAT performed by the router will know how to match the outgoing session with the response from the destination and will make sure that response reaches the initiator located behind the NAT. For that to happen, the client behind to the NAT Router needs to initiate the connection to the external party
But unless you create a specific reverse nat rule aka port forwarding (or UPNP), the router doing NAT will not allow an external IP to connect to a port exposed on the internal client
edited for clarity
Last edited:
If Ned is right, then I have been hallucinating almost 5k hours of Elite play, because I can't open ports on my connection - the public facing IP address belongs to a router upstream from my house, and is shared by all of my neighbors who have the same ISP (I've had opportunies to confirm this while working on neighbors' networks).
I'll repeat yet again: UDP Hole Punching.
I'm not making things up - port forwarding as a solution is just a myth that has become commonly accepted by the gaming community as a whole. At best, it works around a problem without solving it, but it doesn't always manage to do even that. What it does do reliably, however, is convince people with limited understanding of networking that their connections will be better, even if they're no different with or without port forwarding. And it makes it extremely difficult to get people to try actual solutions that really would improve the peer to peer connection, because they all think they've already done everything they can do when they've done nothing helpful. In that respect, the widespread misuse of port forwarding actually causes more problems than people incorrectly think it solves.
Then that router is either UPNP enabled or you are benefiting from FDev's turn servers
edit: even without the above, you can still enjoy multiplayer in ED if other people in your group have some sort of proper port forwarding or UPNP (usually it's the UPNP) since you will be connecting to their sessions and not the other way around
Last edited:
The clients do not have public-facing IP addresses, nor public ports. Their routers do, but the clients don't know anything about those.
The port that the clients use to communicate with the server will not be the same one used when they try to communicate with each other (see below), so this method is doomed to fail.
The router associates an external port with a local IP+port and a remote IP+port. If a non-matching remote IP tries to send a packet to that port, it will be rejected (ICMP destination unreachable).
Likewise, this is why it's impossible for Frontier's server to determine which client port should be used for peer-to-peer connections - the only client port they hear from is the one associated with the connection to their IP; when the client attempts a connection to a peer, it will be through a completely different port on the router because it's a different remote IP+port.
And this is exactly what happens when a router implements port-restricted NAT, which is the most common type because it's cheap and nasty / the most basic to implement.
I've watched your streams, and indeed the amount of issues you experience when trying to play with others is far worse than most people. And if you're behind a CG-NAT with no control over the public interface, it's any wonder you think port-forwarding makes no difference - because in your case it won't.
This is the basic premise you got it wrong in the case of ED and generally speaking for any Peer-to-Peer game that's not using any sort of provider TURN servers/services.
In a P2P game, each game client can be either a client or a server, so it will either connect to a session hosted by another gamer or it will host its own session and allow others to connect.
If you are NAT restricted (no form of port forward or upnp), you can only connect to sessions hosted by other players in the said P2P game.
Edit: i always found this article from XB to be quite explanatory, especially the connections table (who can connect to who in the XB network) - the table behind Why NAT is Important (and it's valid for ED too)
Xbox Support
support.xbox.com
Last edited:
ED's matchmaking works like BitTorrent or any other peer-to-peer filesharing protocol.
If you are behind CGNAT, Elite Dangerous (acting as a server) can't accept incoming connections and is limited in its peer selection.
If you do have a dedicated (also known as public, whether static or dynamic) IPv4 address and configured port forwarding manually but properly, Elite Dangerous (acting as a server) can accept incoming connections and thus has the full selection of peers.
If you do have a dedicated (also known as public, whether static or dynamic) IPv4 address and the router supports UPnP, Elite Dangerous (acting as a server), if UPnP is enabled, will have advertised its selected peer-to-peer port, can therefore accept incoming connections and thus has the full selection of peers.
Elite Dangerous does not use STUN to try and trick two coordinated outbound connections to collide with each other to create an incoming stream.
Elite Dangerous only uses TURN relays if you are in a wing or multicrew session or if it has to to keep the current instance consistent because the only directly reachable peer left the instance.
If you are behind CGNAT, Elite Dangerous (acting as a server) can't accept incoming connections and is limited in its peer selection.
If you do have a dedicated (also known as public, whether static or dynamic) IPv4 address and configured port forwarding manually but properly, Elite Dangerous (acting as a server) can accept incoming connections and thus has the full selection of peers.
If you do have a dedicated (also known as public, whether static or dynamic) IPv4 address and the router supports UPnP, Elite Dangerous (acting as a server), if UPnP is enabled, will have advertised its selected peer-to-peer port, can therefore accept incoming connections and thus has the full selection of peers.
Elite Dangerous does not use STUN to try and trick two coordinated outbound connections to collide with each other to create an incoming stream.
Elite Dangerous only uses TURN relays if you are in a wing or multicrew session or if it has to to keep the current instance consistent because the only directly reachable peer left the instance.
OR you get a colored snake error when the only peer that had proper upnp/port-forwarding leaves the building
(FDev TURN servers do exist, but they are not that many nor that reliable)
Yeah, this can occur if all relay servers are in use. FDev is cheap in this regard, sadly.OR you get a colored snake error when the only peer that had proper upnp/port-forwarding leaves the building
(FDev TURN servers do exist, but they are not that many nor that reliable)
I dont blame them - that the price we pay for a fully free game with no subs and no micro-transactions (and no, i dont count cosmetics as microtransactions since they're really not required)
Or they could have implemented Steam Datagram Relay to try and peer Steam users together or Epic Online Services and use its TURN relays. Both services are free to use. (Even an open source project named OpenTTD considered SDR but then chose to implement their own solution that even asks for consent)
Though i would be wary if FDev made EOS mandatory...
Last edited: