Great work! I especially like how simple the solution ETSN is. I threw together a Go implementation of just that (I'd likely have to redo it for a proper nanomsg port, but it could be generally useful and it was fun and it's only about a 100LOC) But I hit a stumbling block when I got to reading the incoming ETSN message: what do I do if I read more than the message? There are three ways I could handle this in my code. 1. pass a string to the handler of the protocol with any of the extra message 2. wrap the tcp connection type in a new type that keeps an additional buffer of any over-read bytes and exhausts that first before switching to actually reading the underlying socket 3. assume that this will never happen 1 would complicate the users code. 2 is trivial but I'd prefer to hand them the actual connection object if possible. 3 may be a safe assumption but I don't see any guarantee of that. Even if I set my read buffer to 257, the routing message is variable length, so as far as I can see there will always be the chance of getting some of the users information in with the header. There seems to be three possible solutions: 1. always send exactly 257 bytes, 0 or garbage padded, so I know I can read exactly 257 bytes and safely. 2. send back an acknowledgment of some kind, could be a null byte or the string "have at it!" or anything to let the client know it's safe to start sending. 3. leave it up to clients to work around this by 1 or 2 (of the previous list) in the library or an application specific version of 2 (in this list). I like 2 because it let's you know the server heard you and that you (most likely) didn't end up connecting to the wrong service.