

New website of MessagePack Project introduces next-generation RPC. - frsyuki
http://msgpack.org/

======
xtacy
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.

~~~
frsyuki
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.

------
durin42
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?

~~~
frsyuki
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-...](http://msgpack.wordpress.com/2010/05/08/messagepack-rpc-for-cp/) On
the other hand, some uses serialize/deserialize directly on search engine or
caching to pack objects.

------
mkramlich
I like how the site shows sample code on the home page.

Anyone care to compare to Thrift or Google Protocol Buffers?

~~~
tlack
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.

~~~
frsyuki
Message Pack vs similar utilities: <http://gist.github.com/290425>

~~~
tlack
Disturbingly bad results for Bert! Thanks for the helpful link.

