I think trivial protocols like this are a good thing to start with for educational purposes, because implementing one correctly does require quite a bit of effort for someone who has had no experience with networking or RFCs.
Even for something as simple as QOTD the implementer has to consider things like message lengths and interpret terms like "should" (a recommendation, not an obligatory condition for compliance.) Observe that the standard also doesn't mandate that the message must change only once per day, so the implementation presented is compliant. :-)
For TCP Echo, because TCP is a stream-oriented protocol and AFAIK since you can't actually send and receive simultaneously in code - it's always read or write - the question of how much to echo back, and after how long, is also something to consider. Theoretically, an echo server could wait to send until several GB of data were received or the connection is closed, buffering the data limitlessly, and still be compliant. This also shows the importance of being clear and precise when writing standards or protocol specifications in general, should you ever need to do so.
I did consider that scenario, but I suppose what really happens is dependent upon the duplex of the medium, how the network stack handles it (there's certainly a nontrivial amount of synchronisation required...), and if the CPU is multicore. WiFi for sure is half-duplex so I think the two threads will just alternately run.
Comments
I think trivial protocols like this are a good thing to start with for educational purposes, because implementing one correctly does require quite a bit of effort for someone who has had no experience with networking or RFCs.
Even for something as simple as QOTD the implementer has to consider things like message lengths and interpret terms like "should" (a recommendation, not an obligatory condition for compliance.) Observe that the standard also doesn't mandate that the message must change only once per day, so the implementation presented is compliant. :-)
For TCP Echo, because TCP is a stream-oriented protocol and AFAIK since you can't actually send and receive simultaneously in code - it's always read or write - the question of how much to echo back, and after how long, is also something to consider. Theoretically, an echo server could wait to send until several GB of data were received or the connection is closed, buffering the data limitlessly, and still be compliant. This also shows the importance of being clear and precise when writing standards or protocol specifications in general, should you ever need to do so.
AFAIK since you can't actually send and receive simultaneously in code - it's always read or write
Sure you can, there's no problem having a thread writing while another reads in parallel.
I did consider that scenario, but I suppose what really happens is dependent upon the duplex of the medium, how the network stack handles it (there's certainly a nontrivial amount of synchronisation required...), and if the CPU is multicore. WiFi for sure is half-duplex so I think the two threads will just alternately run.