...
The SOP specifies that the client should be the one to initiate friend requests. We specifically call for them to not accept friend requests sent to them for the rescue. This SOP is established not because of a technical reason, but for security. When the client is the person sending the friend request, we can prevent griefers adding the client to their friends list and intercepting the rescue that way. It also reduces the time rats have to spend in menus, giving them more time to jump, rather than handle administrativia.
The bottom line: Rats do not send friend requests. Clients do.
Direction of Wing requests and communications
...
The importance of the client being the originating party lies here; with very little work, rats can ensure that they are "open" for direct connections - meaning that they have a port mapping on their network's router that allows traffic from the internet to reach their E:D client correctly. (See What is NAT and why is it a problem?)
The bottom line: The client initiates wing requests. Rats must clear pre-winged status and relog if they have previously been winged to position near the client.
What is NAT and why is it a problem?
...
There are also a number of pitfalls that may happen even with NAT punchthrough.
- Correctly establishing the connection details. When E:D starts up, it probes the NAT configuration of the host and their router, by sending both packets of UDP data to an EDServer, and a string of configuration details established by the client (Such as port mapping, if negotiated through uPnP). This usually works quite well, but symmetric NAT can cause problems. Symmetric NAT routers establish a separate port mapping for each outgoing connection from the client, meaning that the router might accept incoming packets from IP 1.2.3.4 on port 23333, but expects packets from IP 2.3.4.5 to port 25555. E:D is not able to detect this natively, and thus has to fall back to TURN to punch through such NAT. Manual portmapping evades this problem.
Not having a correct connection details to send to other clients can make syncing for wings problematic. - Double NAT. A NAT router behind another NAT router. Although it is possible to punch through this configuration with TURN, it severely limits connectivity. This is not something we run into often, though.
- Misconfigured manual port forwarding. When E:D is instructed to NOT utilize uPnP to establish a port mapping, and the manual port mapping is not set up, or is incorrectly configured. This will always result in a connection failure, and an attempt to connect using TURN.
Manual drop vs. navlock drop
When dropping on a client, some swear to using manual drops as a 'better' way to ensure instancing. In truth, there is no technical difference between how the attempt to connect between clients is made. Navlock drops just get you dropping faster.
The bottom line: Use navlock drops
Wingless drop
Dropping wingless on the known location of a beacon is a game of chance at best. The matchmaking servers make no effort whatsoever in placing the players on the same playing field without a wing. Dropping on normalspace through targeting a lowwake left by the client is possible, and valid, as that means you are already on the same EDServer.
The bottom line: If you can see the client in Supercruise and can drop on their lowwake, you can do so. But as this carries inherent risks of confusion, the preferred method is being winged with the client. Use this only if the client is having trouble establishing a wing. (I.e, does not understand the instructions to do so, for instance)
Staying in normalspace
Some rats swear to staying in Normalspace at the last known location of a client's beacon. This is also very much a game of chance. Although E:D will prefer to drop players into an instance already spun up and populated with players, it will make no special effort to do so without a wing. The only benefit would be that you would, in the case where the player DOES end up on the same EDServer as you are, you are ready to fire limpets the moment the client enters the game.
The bottom line: Staying in normalspace is a game of chance. To ensure instancing, the game has to be given a chance to move you to the same EDServer as the client. That means dropping on their beacon.
EDServers and how they work
Although E:D is a serverless game, meaning that the players communicate directly with eachother rather than to a server which then transmits the location and actions of all involved players, the game does have matchmaking servers. There are several of these per region, and players are distributed between them to reduce the load on the server for the traffic that does need to go to FDev servers. These are called EDServers, and to successfully instance with another player, you must be connected to the same EDServer. The game has a system to facilitate this when players wing up together. Based on latency and server loads, and to a lesser degree region, the game will move players to a common server. Up until 2.2.3, this mechanism was partially broken, but thanks to amongst others help from us Fuel Rats, these bugs have been greatly reduced.
The move between EDServers happens when you change playfields, i.e when you jump from one system to another, or go from Supercruise to Normalspace. This is why SC hops often helps getting us successful instances; the client gets the chance to move from their EDServer to the same EDServer that the rats are on, the same way that rats have a chance to attempt the move when they drop from Supercruise to Normalspace on their beacon.