The stupid-simple messaging protocol is interesting. However, I would prefer the use of something like D. J. Bernstein&#x27;s netstrings rather than NL terminated strings. Netstrings have the advantage of having an explicit length field and thus allowing the receiver to allocate buffers of the appropriate size without the complications of receiving NL terminated data. Examples of protocols using netstrings are SCGI and QMQP. Netstrings are easier to handle and are still easy to debug if verbs are expressed in ASCII while still handling arbitrary binary data equally well.<p>Netstrings are so brilliantly simple, see the wikipedia page: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Netstring" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Netstring</a><p>This is what DJB says about the netstrings [1]:<p>&gt; The famous Finger security hole may be blamed on Finger&#x27;s use of the CRLF encoding. In that encoding, each string is simply terminated by CRLF. This encoding has several problems. Most importantly, it does not declare the string size in advance. This means that a correct CRLF parser must be prepared to ask for more and more memory as it is reading the string. In the case of Finger, a lazy implementor found this to be too much trouble; instead he simply declared a fixed-size buffer and used C&#x27;s gets() function. The rest is history.<p>&gt; In contrast, as the above sample code shows, it is very easy to handle netstrings without risking buffer overflow. Thus widespread use of netstrings may improve network security.<p>[1] <a href="http:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt</a><p>BTW, see Aaron Swartz&#x27;s blog post on DJB, <a href="http:&#x2F;&#x2F;www.aaronsw.com&#x2F;weblog&#x2F;djb" rel="nofollow">http:&#x2F;&#x2F;www.aaronsw.com&#x2F;weblog&#x2F;djb</a>