Page 1 of 2

Friday Facts #149 - Deep down in multiplayer

Posted: Fri Jul 29, 2016 10:50 pm
by kovarex

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Fri Jul 29, 2016 10:53 pm
by kinnom
read it before you put the link here up :P

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Fri Jul 29, 2016 11:07 pm
by Zirr
Interesting read. I love the technical Friday (saturday? :)) Facts.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Fri Jul 29, 2016 11:44 pm
by Supercheese
Zirr wrote:Interesting read. I love the technical Friday (saturday? :)) Facts.
It's definitely still Friday here, at least.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 12:13 am
by Ratzap
This kind of thing is close to my professional work so I love these types of Friday facts. Technically it wasn't on a Friday but we'll let you off.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 12:20 am
by bk5115545
Probably the most interesting Friday Fact yet.

I especially like the flow charts.

Question: What will happen if the newly-connected client can't finish the "catch-up" phase;
Tick rate decrease or disconnect or something else (maybe even undecided)?

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 12:45 am
by tehroach
bk5115545 wrote:Probably the most interesting Friday Fact yet.

I especially like the flow charts.

Question: What will happen if the newly-connected client can't finish the "catch-up" phase;
Tick rate decrease or disconnect or something else (maybe even undecided)?
From what I read, I assumed that the slower player will just keep receiving packets, will never catch up and the player will be forced to click the disconnect button, mean while the players playing will continue playing and be blissfully unaware of the slow players problems.

Ohh I really can't wait to be able to play this game with people in other countries :)

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 1:00 am
by self-same-spot
.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 3:38 am
by nonstickfrypan
self-same-spot wrote:
As the peer-to-peer network model is being removed, this is not needed anymore and every communication has it's own numbering,
I've kept my mouth shut the first twenty times this happened in the blog and changelogs, but I can't anymore. Sorry for pedantry:
Thanks for clearing that up! Its something that annoy's me as well; its as if people have never heard of an apostrophe so they either leave it out or add one at random where they think its appropriate. The apostrophes property's are confusing but its easy to learn.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 5:23 am
by Hamster
nonstickfrypan wrote:
self-same-spot wrote:
As the peer-to-peer network model is being removed, this is not needed anymore and every communication has it's own numbering,
I've kept my mouth shut the first twenty times this happened in the blog and changelogs, but I can't anymore. Sorry for pedantry:
Thanks for clearing that up! Its something that annoy's me as well; its as if people have never heard of an apostrophe so they either leave it out or add one at random where they think its appropriate. The apostrophes property's are confusing but its easy to learn.
I learned it that way, that every
it's = it is.

So the best is to "replace" it with the long variant, and check if the sentence is still correct:
communication has it's own numbering. = communication has it is own numbering

As we see it, it's not.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 8:01 am
by ChurchOrganist
Ratzap wrote:Technically it wasn't on a Friday but we'll let you off.
Actually it was - according to the forum time stamp Kovarex's post was at 22:50 UTC on Friday 29th July.

But as most of us are on daylight saving time at the moment it may have appeared that the post was on Saturday.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 8:32 am
by Blubberbub
So if the attacker knows the server ID, he/she can still run the same attack by sending 2 instead of 1 packet to the server? Or is the server ID random and different for every player?

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 9:07 am
by Loewchen
Blubberbub wrote:So if the attacker knows the server ID, he/she can still run the same attack by sending 2 instead of 1 packet to the server? Or is the server ID random and different for every player?
The attacker can't respond as he fakes the victims IP or he would DDOS himself ;).
He would get one packet send to the victim for 1 packet sent by himself instead of 700 for 1.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 9:26 am
by Blubberbub
Loewchen wrote:
Blubberbub wrote:So if the attacker knows the server ID, he/she can still run the same attack by sending 2 instead of 1 packet to the server? Or is the server ID random and different for every player?
The attacker can't respond as he fakes the victims IP or he would DDOS himself ;).
He would get one packet send to the victim for 1 packet sent by himself instead of 700 for 1.
Why would the attacker not be able to respond if he knows the response?
  • Attacker connects to server by himself and figures out the server-id.
  • Attacker sends first spoofed packet with client-id
  • Server sends first response to victim. Will probably be discarded.
  • Attacker waits a little
  • Attacker sends second spoofed packet with client-id + server-id
  • Server starts sending a lot of data to the victim

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 9:39 am
by Loewchen
Blubberbub wrote:
Loewchen wrote:
Blubberbub wrote:So if the attacker knows the server ID, he/she can still run the same attack by sending 2 instead of 1 packet to the server? Or is the server ID random and different for every player?
The attacker can't respond as he fakes the victims IP or he would DDOS himself ;).
He would get one packet send to the victim for 1 packet sent by himself instead of 700 for 1.
Why would the attacker not be able to respond if he knows the response?
  • Attacker connects to server by himself and figures out the server-id.
  • Attacker sends first spoofed package with client-id
  • Server sends first response to victim. Will probably be discarded.
  • Attacker waits a little
  • Attacker sends second spoofed package with client-id + server-id
  • Server starts sending a lot of data to the victim
If the attacker would connect himself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 9:47 am
by Blubberbub
Loewchen wrote: If the attacker would connect itself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.
Image
The image suggests, that the client presents its client-id to the server. (I would like to URL it, but apparently that starts a download of the image which is inconvenient...)

The attack is only prevented if there is secret information send from the server to the client in the Connection Reply packet. But from the text and diagram it looks like there is only the client-id (which is send from the client to the server in the Connection Request, so the attacker can choose one) and the server-id (which is presumably the same for all clients on the server).

EDIT:
The client first generates (randomly) his id, and sends it to the server as part of the request. The server generates his unique random id as well, and sends it back to the client.
The client id is randomly chosen by the attacker, so it does not add anything to the ddos prevention. The wording of "his unique random id" suggests, that the id is unique to the server. For the prevention to work the server id has to be different and unique for every client and not unique for every server. Maybe its just a wording issue. I hope it is.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 10:05 am
by universal
the ability to have the server bind to a specific ip and not 0.0.0.0 would be great ;)

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 10:08 am
by Loewchen
Blubberbub wrote:
Loewchen wrote: If the attacker would connect itself he would get his own clientID but he would need the clientID of the victim which he can not get as it is sent to the victims IP.
The image suggests, that the client presents its client-id to the server.
Indeed, that would make it necessary for the ServerID to be unique between the clients.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 10:37 am
by Zulan
This is a really interesting read. There is just one thing that keeps puzzling me. Is there not a good framework out there that you don't have to write and maintain that code yourself? It's not like this is the first multiplayer game. The latency hiding seems to be the only thing that has game-specific aspects as it sort of needs to roll-back state. The rest just feels completely generic to almost all games that don't exclusively simulate the world on the server.

Re: Friday Facts #149 - Deep down in multiplayer

Posted: Sat Jul 30, 2016 12:14 pm
by J├╝rgen Erhard
Please, kovarex, at least stop thinking about multiplayer when you ride your bike and *CONCENTRATE ON THE TRAFFIC*!

;-)