7 ms·
New website of MessagePack Project introduces next-generation RPC.
- mkramlich 16y agoI like how the site shows sample code on the home page. Anyone care to compare to Thrift or Google Protocol Buffers?
- tlack 16y agoAlso 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.
- xtacy 16y agoHow 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.
- frsyuki 16y agoIt 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.
- durin42 16y agoI'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?
- frsyuki 16y agoIt'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-cp/ 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.