5 ms·
I'm not an expert, but don't you have the timeline wrong? E.g. Luby's "LT codes" is from 2002, well after Quake's 1996 launch date. Honestly, though, I think t
by JoachimSchipper 15y ago
I'm not an expert, but don't you have the timeline wrong? E.g. Luby's "LT codes" is from 2002, well after Quake's 1996 launch date.
Honestly, though, I think the Quake guys were going for - and achieved - "good enough".
(Also, coding obviously doesn't work for client -> server communication, since the server has to keep going even if packets are lost.)
- imurray 15y agoI agree Luby's codes came after Quake. Although other codes for the erasure channel did exist, and the important ideas for the class of scheme I'm talking about were known. That wasn't meant to be my point though. I was just thinking about the puzzle, rather than what "should" have been done. I don't follow the final parenthetical comment: the point of the coding is precisely so that the server can recover all information regardless of packet loss so that it can keep going. If a client disappears then the server acts as if it disappeared at the last successfully decoded delta (it has to have a means to deal with clients disappearing regardless).
- JoachimSchipper 15y agoRegarding my parenthetical comment: the server can ignore input that was not received in time, block while waiting for input, or try to "rewind" the world. The first is lossy, the second leads to the same hiccups as reliable transmission protocols (although the effect may be smaller), and the third leads to "paradox" (and lots of complexity). There are no really good solutions here. I agree that such codes are interesting, though - I really should know more coding theory...