[nanomsg] Re: RFC links

  • From: jimmy frasche <soapboxcicero@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Fri, 9 Aug 2013 17:33:23 -0700

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.

Other related posts: