That is not a TCP/IP stack in 200 LoC. The thing described is a TCP/IP segment parser with response packet encoder.
The “stack” described [1] can not transmit a payload stream. That also means it avoids the “costly (in terms of lines)” problems of transmit flow control and “reliable send” guarantees in the presence of transmit pipelining needed for even modest throughput. For that matter, it does not even reconstruct the receive stream which is, again, one of the more “costly” elements due to data allocation and gap detection. It also does not appear to handle receive side flow control either, but that could be hidden in the TCP receive engine state which is not described.
These are not minor missing features. The thing described does not bear any resemblance to a actual TCP implementation, instead being more similar to just the receive half of a bespoke stateful UDP protocol.
Now it is possible that the rest of the TCP/IP stack exists in the other lines, as only about 25-ish lines are written down, but you can conclude almost nothing from the described example. The equivalent C code supporting the same features would be similar-ish (under 100 lines) in length, not 10,000 lines. That is not to say it is not a tight implementation of the feature set, but it is not reasonable to use it as evidence of multiple order of magnitude improvements due to representation superiority.
I agree --- I mostly think it's interesting as one of the most concrete examples of what they claim to have actually done that I've been able to find.
In general, it's frustrating that, as far as I can tell, they don't seem to have made any of the code from the project open source. Widespread skepticism about their claims due to this is (IMO) justified.
The “stack” described [1] can not transmit a payload stream. That also means it avoids the “costly (in terms of lines)” problems of transmit flow control and “reliable send” guarantees in the presence of transmit pipelining needed for even modest throughput. For that matter, it does not even reconstruct the receive stream which is, again, one of the more “costly” elements due to data allocation and gap detection. It also does not appear to handle receive side flow control either, but that could be hidden in the TCP receive engine state which is not described.
These are not minor missing features. The thing described does not bear any resemblance to a actual TCP implementation, instead being more similar to just the receive half of a bespoke stateful UDP protocol.
Now it is possible that the rest of the TCP/IP stack exists in the other lines, as only about 25-ish lines are written down, but you can conclude almost nothing from the described example. The equivalent C code supporting the same features would be similar-ish (under 100 lines) in length, not 10,000 lines. That is not to say it is not a tight implementation of the feature set, but it is not reasonable to use it as evidence of multiple order of magnitude improvements due to representation superiority.
[1] https://worrydream.com/refs/Kay_2007_-_STEPS_2007_Progress_R... Page 44