3 ms·
Interesting. But wouldn't this mean some clients would need to wait a long time for their download to start? (I'm imagining a multi-gigabyte game update - but m
by chatmasta 3y ago
Interesting. But wouldn't this mean some clients would need to wait a long time for their download to start? (I'm imagining a multi-gigabyte game update - but maybe you meant a continuous stream of in-game positional updates of players.) They basically idle until the next "train" shows up at their station, and then they hop on, right? Also, if they have a network hiccup, they can't resume their download until one of the trains reaches the point where their download failed.
(That is, if you get my weird train analogy, and if I'm understanding your idea correctly.)
- foota 3y agoI was thinking of a game like minecraft or similar (essentially, a ~large world with lots of entities updating in a grid of chunks). In that case, you generally have people fairly clustered in different grid tiles, and they're all likely to get similar information about each chunk, so it seems like re-using the buffers between calls would be beneficial. So instead of: for each player: for each block player needs: # Write block to player's connection You could do: for each player: for each block player needs: # Check if the block is already mapped in a kernel buffer. If it is, just append a write for it to the io ring. # Otherwise, copy the block into a new buffer and send it.