Also curious about how this compares to BERT, which uses Erlang's binary term format, which makes sense to me since so much infrastructure uses Erlang these days.
How is the transport layer implemented? Does it use TCP? Or does it build its own reliable transport over UDP? Of another concern is the message delivery latency.
It basically uses TCP. Raw unreliable UDP is also supported on Ruby and Java. TCP or UDP will be enough choices for most of applications. Practically, MessagePack-RPC mainly focuses on cross-language communication, like Ruby frontend <-> C++ backend. So portability is rather important.
I'm not sure I understand the obsession with speed here - at some point isn't the RPC latency going to be the dominator rather than the encode/decode time? Shouldn't we be really close to that already for well-designed applications without a ton of RPC roundtrips?
It's true that network latency is dominator rather than serialization. But low CPU/memory usage is still important for CPU/memory-bound applications. Especially, zero-copy feature is effective to raise maximum throughput.
As for RPC performance, parallelism will be important for high-load systems. It's described at http://msgpack.wordpress.com/2010/05/08/messagepack-rpc-for-...
On the other hand, some uses serialize/deserialize directly on search engine or caching to pack objects.
8 comments
[ 1.9 ms ] story [ 33.8 ms ] threadAnyone care to compare to Thrift or Google Protocol Buffers?