MessagePackで圧縮をサポートして節電する！

Muga Nishizawa @muga_nishizawa

@frsyuki thrift は B か C だった気がします。

Kazuki Ohta @kzk_mover

@muga_nishizawa Cですね > TZlibTransport

Sadayuki Furuhashi @frsyuki

A案のデメリットは、オブジェクト単位でエントロピー圧縮するので、圧縮率が低くなる点。小さいオブジェクトをチマチマ圧縮してもオーバーヘッドが大きいだけ。TCPでメッセージをやりとりするケースとか、似たオブジェクトがズラーっと続いている場合、ストリーム全体を圧縮した方が圧縮率が高い。

kuenishi @kuenishi

GoogleがProtobufと併せて圧縮周りをいろいろ工夫しているのは知ってた。OSSになってるのは知らなかったぉ

Muga Nishizawa @muga_nishizawa

@frsyuki はいー Java 版の MessagePack-RPC には、いろいろ差せる機能があるので、そこをうまく使えると良いなと思いますよ

Kazuki Ohta @kzk_mover

@kuenishi 昨日か今日に、OSS化されたんですお!

Muga Nishizawa @muga_nishizawa

そうか、Transport 部分ですか、なるほど。

kuenishi @kuenishi

@kzk_mover そこだけチョロチョロっとC拡張呼ぶとかは簡単なので、ポータビリティの問題ですね。snappyはWindowsでも動くの？とか。

Sadayuki Furuhashi @frsyuki

Bを飛ばしてC案のメリットは、ストリーム単位で圧縮できるので圧縮率が高い点。それから、現状のMessagePack-RPCのプラガブルな部分に新たなプラグインを加えるだけなので、後方互換性を保ったまま実装もしやすい。

d-kami @d_kami

Message PackのA案ってどれくらい圧縮できるんだろう？

Kazuki Ohta @kzk_mover

@kuenishi なるほどー。MessagePack-RPC for C++は... 現状ではWindowsでは動かないみたいですw

kuenishi @kuenishi

@kzk_mover えっｗｗｗてそりゃそうか。ソケットまわりまでいちいち移植してらんないですね。

Sadayuki Furuhashi @frsyuki

C案のデメリットは、A案のメリットが無いことか。RPCに実装しても、RPCでしか圧縮使えない。アプリケーション毎に圧縮ストリームの実装が必要。ただこれはMessagePackのライブラリで便利APIとして圧縮出力をサポートすれば十分可能か。

kuenishi @kuenishi

Msgpack/Erlang should be as portable as erlang runtime, Msgpack-RPC/Erlang need not be portable, it seems enough supporting Linux and BSD.

Sadayuki Furuhashi @frsyuki

B案のメリットは…なんだろう^^; C案だとTCPとUDPの両方で圧縮が使いたくなったら、2箇所で圧縮サポートを実装しないといけないところが、B案だと1箇所で済む点か。イマイチ感。

SKS rep @repeatedly

SnappyはWindowsでも動くのではと思ってるんだけど，64bitの方がやっぱりいいのかなと感じる．

Sadayuki Furuhashi @frsyuki

で、はい。C案（+MessagePackライブラリで圧縮出力を提供）が良さそうな気がしてます。

Kazuki Ohta @kzk_mover

C案++

Muga Nishizawa @muga_nishizawa

+1

Sadayuki Furuhashi @frsyuki

ぁB案はネゴシエーションが可能というメリットが。通信相手が圧縮をサポートしていなかったら圧縮なしにフォールバックするような。ただこれのサポートするのは実装がわりと面倒だし、ネゴシエーションに通信時間がかかるのは微妙というデメリット。

SKS rep @repeatedly

d_kami先生がとりあえずA案を実装して試してくれると聞いて RT @d_kami: Message PackのA案ってどれくらい圧縮できるんだろう？

Hideyuki Tanaka @tanakh

@frsyuki サーバ・クライアントがサポートしているプロトコルの種類を教えられるようにしてもらえると、貧弱なライブラリでもおはなしができてうれしいかもしれません。

Sadayuki Furuhashi @frsyuki

なるほど…なるほど。 RT @tanakh: @frsyuki サーバ・クライアントがサポートしているプロトコルの種類を教えられるようにしてもらえると、貧弱なライブラリでもおはなしができてうれしいかもしれません。

kuenishi @kuenishi

バージョンの話は早めにおいついておきたいな。IDLは…Erlang的にはbehaviourで十分で、うーんという感じ。余計なコードがほとんどないのであんまり嬉しくない。日付・時刻型はまあ書けばできるか。

Sadayuki Furuhashi @frsyuki

C案を現状の仕組みの上にそのまま実装すると、圧縮をサポートしていないRPCクライアントのサポートは、いわゆる「運用で回避」という感じになるハズで、具体的には圧縮ありは 19800/tcp でlistenして、圧縮なしは 19801/tcp でlistenするような。