Are the dumb fucks that complain about peer to peer connections being a bad thing in over their heads...

are the dumb fucks that complain about peer to peer connections being a bad thing in over their heads? specifically i'm talking about For Honor. They all seem to think that p2p instead of a dedicated server is what's causing its network problems. Theoretically though, for a 2 player game this should be better shouldn't it since you aren't having to communicate via the server with each other, right?

Player A lives on the west coast, player B lives on the east coast. They connect to each other, causes much lag.

Player A lives on west coast, Player B lives on east coast. hey connect to a server in the middle. Lag aint that bad.

what's the trip time for player A's movements to be sent to player B via the server?

Translation:
>I don't know what ping and latency is

obviously you don't since ping and latency are the same thing.

...

>*or
Happy now?

P2P is actually good because (((they))) can't shut down the servers as easily

latency is the time delay for the electrons or in the case of fibre, photons to travel from 1 location to another location. so if anything this validates my theory, it does not disprove it.

His post is pretty straightforward and easy to understand. If you don't get it, then you don't understand basic networking

Your "theory" isn't a theory. It's an incorrect claim backed by a lack of understanding

Just as long as the company lets other people make servers then you can't really shut down servers. Main reason games like cs1.6 is still up and running.

>You don't understand basic networking

The data still has to be sent out to the clients, the total travel time hasn't changed you just changed the speed at which you communicate with the server itself. If it takes 100ms for player A to see a move player B makes in a P2P setting then it's still going to take that long if you slap a server in between them.

Not really. Consider two players, 200ms apart, and a server in the middle, 100ms away from both of them. If you connect both of them to each other, the host (A) gets their client side prediction validated immediately and the other player (B) gets their client side prediction validated after 200ms. Using the server it's a more fair 100ms for both of them.
If A moves, B will hear about it 200ms later in both architectures. There is unlikely to be much additional latency as it moves through the server, probably a millisecond or two at most and because there is still a server on A's machine depending on your engine architecture you may still get that latency under P2P.
Even for two players a dedicated server provides a more equal experience.

I suspect however the problem relates more to other factors.
1. Shitty routing. Back in the old days I used to use P2P chat on Xbox and Skype. There were people I simply could not speak to unless I had another person in the voice call to "stabilize" it because of shitty routing. One guy in particular didn't live more than 40km from me and was simply impossible to talk to without someone else to stabilize the connection.
2. Shitty domestic internet connections. A lot of people still have crap connections, particularly poor upload speeds, which are very important for hosting game servers.
3. Shitty host positioning. I don't run a large P2P game, but I would imagine that when you have only say, eight people in a game, you have to make some pretty hard choices about hosting. Many people may have NATs too restrictive to let them host, many people will have garbage upload speeds/latency/etc. You have to pick from the remaining pool and if the remaining pool is one guy who's pretty far away from the other players, you're up shit creek without a paddle quite frankly.

as is your post

This isn't about just player A though. Here is a scenario.

Player A is hosting. It takes 0 time for their actions to be processed and sent back to them.

Player B is on player A's server. It takes 100ms for the server to get player B's action, so it takes player A ~100ms to see that action (remember cuz 0 time). You addressed that, so we are good there.

Player B won't see his action for another 100ms though. (Return time). So player B is 200ms behind player A, which sucks.

Now slap a server in the middle. Both A and B have a 50ms travel time (100ms with return). The total latency has not changed obviously, but now both players are on an even field. There is a 100ms delay for both players. If someone is hosting, they will always have an advantage.

It was an issue with Halo 2, as the host would always win BR duels if both players were hitting head shots

No, this is my post.

You can't look at total latency between multiple players and call it even. That is the reason Riot moved the league servers to Chicago, a more centralized area to the US. Obviously people in central US have better ping, but now the East coast isn't fucked

this can easily be fixed by inducing an artificial delay for player A equal to whatever player B's latency to A is

Ok that's a fine solution, not considering the difficulties associated with it, but do you understand the reasoning behind what I'm saying and how it answers OP's lack of understanding?

Let me also say that P2P connections are not easily done either. NAT punching is VERY difficult to do. It also gives the player hosting the game more power than you want to give someone

Then everyone's on garbage ping, you haven't solved anything, you've just made it equally shit. What is actually done is the server rewinds time when it receives synchronization critical inputs like firing a gun and applies them as though they had arrived whenever what the player is currently seeing was the truth (within a range). But even with this, artificially increasing ping (even further, it's already done for interpolation) is a bad idea as the further behind the client is the more likely their client side prediction will misfire and the more bullshit the rewinding will feel.

>NAT punching is VERY difficult to do.
Can confirm, it's misery to implement and totally impossible with some connections.

>NAT
This is 2017.
IPv6.

Unfortunately we live in the real world where IPv6 is still a pipe dream in any large consumer facing system.

Are you suggesting every endpoint have a unique IP, because that would make it impossible to find anyone you haven't discovered. Protocols like NAT won't go away