Discard duplicate packet numbers (and unreliable messages) about gamenetworkingsockets HOT 6 CLOSED

Curious, does this also apply to the current live steam network? Attacks are basically trivial without replay protection. Would be very curious if it passed the security layer. And how are fragments to be handled?

Bit broader but still related are the out of order packets, also more common.

from gamenetworkingsockets.

Is this repo dead yet?

from gamenetworkingsockets.

@Mellnik There's a lot of work going on in another branch, addressing the first item on the roadmap.
https://github.com/ValveSoftware/GameNetworkingSockets/commits/snp-rewrite

from gamenetworkingsockets.

@fletcherdvalve Are you open to comments or is it pretty much a done deal? Asking because if indeed you're basing it on QUIC, I think there is a misunderstanding about their intent. Not sure even Google knows what they were smoking^Wthinking. It's faster but fragile, completely falls apart on some networks.

from gamenetworkingsockets.

@h1z1 I would definitely be interested in your opinions. I would say the main thing we got from Google QUIC was just the high-level idea to use packet-level acks instead of a simple sliding window. We didn't do the ACK encoding exactly like they did, we just used the basic idea that a richer ack protocol would result in less backing up and re-transmission. I've tested the code we have under some pretty horrendous simulated network conditions and it survives. (Although I haven't directly compared it to TCP yet.)

It is definitely more complicated than sliding window, I agree 100% on that. My assumption is that spending a bit more more CPU and memory to reduce re-transmission is the correct tradeoff right now for most use cases.

You can take a look at the encoding and approach in the snp_rewrite branch now.
https://github.com/ValveSoftware/GameNetworkingSockets/blob/snp-rewrite/src/steamnetworkingsockets/clientlib/SNP_WIRE_FORMAT.md

from gamenetworkingsockets.

Fixed.

from gamenetworkingsockets.