Buffered transport for binary protocol

[aawilson]

Currently, the only client/server implementations over the binary protocol are with framed transport. It would be swell if elixir-thrift could also generate implementations that use "unframed" (as described in the section "Framed" vs "Unframed" of the doc here) (I've also seen it referred to as "buffered", as in the thriftpy2 implementation here, although I don't know if their use of terminology makes sense given the salient difference seems to be not buffering incoming frames, but that could be my misunderstanding) transport, instead.

I looked at implementing this, but for the life of me, I can't see where thrift/framed/protocol_handler.ex is handling the framing, meaning I either just have poor elixir reading comprehension (which is a fair cop), or it's happening somewhere in the :gen_tcp module. I'm happy to keep staring at this in my free time, but pointers would be appreciated if available.

[pguillory]

The framing is done by setting the {:packet, 4} option on the socket in Thrift.Binary.Framed.ProtocolHandler. It's built in to gen_tcp and conveniently does the right thing for this purpose. See the docs here.

However the tricky part for implemented unframed transport will probably involve how the generated deserialization code assumes the entire message is available, which was both for simplicity and performance. When it fails, it just returns :error. It would need to be modified to instead return some kind of continuation that could be used to resume deserialization when more data arrives.

[aawilson]

Thanks for the pointer, I was suspicious about how convenient that 4 was in the options there but couldn't find the documentation in gen_tcp that pulled it together, so I appreciate it. I've got some good models for how other projects handle this lying around so hopefully I can take a stab at something passable.