TCP Packets

[ddyer]

Remember that the tcp guarantee of reliable delivery is only operative at the tcp stream
level where the checksum is checked or generated. There’s a lot of software between your
application and the low level TCP driver, and your only guarantee there is hope and best
wishes.

I run an application that keeps its own checksum at the application level, and still get
checksum errors at rare intervals - currently running at one error per 200 million transactions.
Note that this is an “all causes” count, not limited to transmission errors. Still, it’s sobering
to consider that even “reliable” channels are not.

[Riven]

@ddyer

I run an application that keeps its own checksum at the application level, and still get
checksum errors at rare intervals - currently running at one error per 200 million transactions.

@Riven

Indeed, there is however a tiny chance that the corrupted checksum matches the corrupted payload. On a busy server, a few monster packets per year are to be expected.

Don’t forget RAM and disk errors.

[i30817]

Why things like ZFS are important no.

Please don’t remove my simplicity plz…

Anymore than it already is.

[DzzD]

@Riven

Don’t forget RAM and disk errors.

this is something that have recently afraying me when I discover the “ressource monitor” showing material memory error on window… so many error , up to 12/min for some process :o … so much fear that I decided to close this monitor window suddently ! while it stay closed cant see any error and all seems to be ok

[Nate]

@Alan_W

The nice thing about NIO is the ability to process the data in the main game thread without blocking it.

Do you guys think it is OK to do NIO selects on the game’s render thread? I have been running a separate thread to do network read/writes, then queuing any data read to be processed in the game thread. Which approach would be preferred? I was worried that the network IO might affect the framerate.

[Riven]

@Nate

Do you guys think it is OK to do NIO selects on the game’s render thread? I have been running a separate thread to do network read/writes, then queuing any data read to be processed in the game thread. Which approach would be preferred? I was worried that the network IO might affect the framerate.

In ‘C land’ network code is (or used to be?) part of the main loop. Everything is easier with only one thread.

It certainly makes code simpler… but networking I/O is rather ‘expensive’ due to interacting with the kernel, so why not give it its own thread? In the end it doesn’t really matter, as you probably have one low-traffic connection to the server, in the typical multiplayer game.