けいぞうのメモ帳

言語設計のお勉強

haskellでbinaryにread&write

binary packageのGet/Put Monadを使いBinary classにgetとputを実装することでData.ByteString.Lazy.Internal.ByteStringとデータ構造を変換する事ができる。

ネットワークプロトコルフォーマットパーサの実装の参考として、http2 packageを覗いた。 unsafeperfomeIOを使ってWord8をPtr aとして扱っていた。おそらくこれは高速化のためだと思うのでベンチマークをあとで取ることにする。

gistaa91f312fdf7acb5c8a0e58a558ca8eb

haskellでUDP

間違えてTCPのサンプルを置いていたから修正した。

UDP

user datagram protocol.

https://www.ietf.org/rfc/rfc768.txt

HeaderのadressはIPv6時にはちゃんと128bitに変わる。

haskell network

Network.Socket.ByteString

俗に言うhaskellで書くC言語のコードである。 simpleにTCPでつなげるなら、networkのNetwork.Socket.ByteStringのサンプルが良い。

UDP

[Haskell-cafe] UDP client/server

をforkしないコードにして置いた。

stackでbuildできるようにした

gistb09bbfd263b61fa180256d14c41810e6

QUIC追っかけ日記01

QUICについて

Googleが主導しているHTTP+TLS+TCPに変わる新たなプロトコル
アップグレードされたHTTPにたいしてそのTLS+TCPの部分を効率よく通信するために策定されている。 まだインターネットドラフト段階で、

https://tools.ietf.org/html/draft-ietf-quic-transport-00 がJune 1, 2017まで議論される様子。
このrevisionから更新を追いかけていきつつQUICについて記述する。

公開して、意図を訂正してもらう目的が大きいため、なんらかの参照にするのは望ましくない。

改善点

よく取り上げられる順番で書いていく。

Head of Line blocking (HOL blocking)

Head-of-line blocking - Wikipedia

Head of Line Blocking - High Performance Web 2015 - Qiita

HTTP/1.X or TCPの通信は並列化されていないため、複数のストリームを一つのコネクションを用いて流す場合、
直列に送信するため先行するストリームが重かったり、輻輳が発生したりすると、送信時間や再送時間分だけ後続のストリームが 到達する時間が遅くなる。

HTTP1.1のRFCの邦訳

https://triple-underscore.github.io/RFC7230-ja.html#section-6.4

によると、

複数接続は、概して, “head-of-line blocking” 問題 — [ サーバ側に重い処理を要したり, 巨大なペイロードを持つ ]ような要請が、同じ接続上の後続の要請を阻むこと — を避けるために利用される。 しかしながら、接続のそれぞれは,サーバリソースを消費する。 更には、複数の接続が利用された場合,混雑したネットワークに,望ましくない副作用をもたらし得る。

とあるため、HTTP1.1においてもTCPのコネクションを複数接続させることでHead of Line Blockingを避ける場合もある。 ただし、そういった場合にはTCPのコネクションを複数もつリソースだけ余分なリソースが消費される。増やしすぎるとTCPのコネクションのリソース消費と並列化による高速化が釣り合わなくなるため、 TCPのコネクションをむやみに増やせばいいというものではない。例えば、chromeは6本の固定値である。

HTTP/2そしてQUICにおいては一つのコネクション上でストリームが並列に送信され、輻輳制御もストリームごとに行われるため、Head of Line Blockingがそれぞれのレイヤで発生しなくなる。 HTTP/2 over QUICを用いれば、上記の理由によるHead of Line Blockingは発生しなくなる。

TLS + TCP

TCPでスリーウェイハンドシェイク、TLSでセッション鍵交換を行ってから、HTTP/2 over TLS over TCPの通信が行われる。
これを冗長とし0RTT つまり要求してすぐに通信が始まるようにQUICは設計される予定だ。 ID 0のストリームでコネクション要求とTLS接続に用いる情報、clientのQUIC versionをサーバに渡し、サーバのQUIC versionの比較とデータの送受信を始める。

QUIC Wire Layout Specification - Google ドキュメント

FEC

前方誤り訂正を用いて、一割程度の損失があった場合でも回復できるようにしていたらしい。

QUICはXORベースのFECをやめるらしい - あすのかぜ

QUIC FEC v1 - Google ドキュメント

chrome-devとyoutubeを用いた検証では芳しくない結果が出たためFECの仕様を改めて決める。

rust langでturing machineもどき

github.com

rustの線形型やリージョン推論をすごいすごい言っていたりするのにコードを書いていないのは良くないので、 rust langの練習用にチューリングマシンエミュレータのようなものを作った。

あまり説明する気のない説明

状態Sと、記号と空白記号の集合Lをenumを使った代数的データ構造で定義し、
関数stepをs ∈ Sとテープ上の l ∈ Lによって状態を遷移させる遷移関数とする。sとlはmatch syntaxで判別する。
テープは構造体で表し、Vectorと現在の参照位置をusizeで持った。

enum L {
    Blank,
    X,
    One,
    Zero,
}


let mut tape = [L::Blank, L::One, L::Zero, L::Zero, L::One, L::Blank ];

これは 1001 を表す

{0,1}で表される単語wとその反転reverse w = w'が並んでいるww'なテープを得たときのみState::start()がtrueを返す。 雰囲気はテストコードを見て感じ取って欲しい。

$cargo test
or 
$cargo run 

で9つのテストコードかmain関数が走るようになっている。

ちょっと大変だったこと

テープの表現は

struct State<'a> {
    tape: &'a mut Vec<L>,
    ptr: usize,
}

と書いている。
Vectorで無限長のテープの表現、ptrで今の参照位置だ。変数名ptrなのにvalueなのが気持ち悪いとか言わないで欲しい。 しばらくの間は

struct State<'a> {
    tape: &'a Vec<L>,
    ptr: usize,
}

としていたのだけれど、これだと

impl<a'> State<'a>{

  fn assign(&mut self, n : usize, v : L) {
     let ref mut tape = self.tape;
      tape[n] =  v;
  }

}

のような関数はコンパイルエラー。なぜかというと、selfはmutableでborrowingしているのにVectorはimmutableになって変更できないため。
構造体内の参照はmutable or immutableを選べるとはしらなかった。 あとlet ref mut tape = sefl.tape.clone()vectorの参照をclone()してくれると思って書いていたら値も丸ごとcloneしていた。

fn f(v : &mut Vec<usize>){                                  
    let mut vec = v.clone();                                
    vec[1] = 1;                                             
}

fn main() {
    let mut vec : Vec<usize> = vec![0,0,0,0];
    f(&mut vec);
    for v in &vec {
    println!("{}", v);
    }
}

--出力
0
0
0
0

次のお題

マークアップ言語パーサを書く。

mrbox -- mruby binary manager -- を改めて紹介する

mruby advent calendarで書いたmrubyのバイナリを管理するmruby-cli wareがとりあえず困らない程度に実装出来たのでご紹介します。

mruby

以前書いた記事を参照ください。mruby1.0.0だか1.1.0の頃の話ですが変わったところはないと思います。

keizobookman.hatenablog.com

動機

mrubyを使って開発をしているときに、必要なgemを組み込んだmrubyの実行バイナリが必要になります。 しかし、mrubyのライブラリはstatic linkでgemを加えたいときは毎回リビルドが必要になります。 さらに、開発・テスト・本番で組み込みたいgemが違う場合は結構あり、それを手元でよしなにする方法がありませんでした。

mrbox

github.com

そこで実装したのがmrboxです。mruby sandboxの略のつもりで名前をつけました。"えむるぼっくす"か"えむるおーえっくす"かは各自好きに読んでください。
MacとArch Linuxを移動しながら開発していたのでそれらでの挙動はある程度保証できます。Windowsはビルドが出来なかったのでまだサポートしていません。
手持ちのWindows機は開発環境が整っていないのでv1.5とかv2.0とかでの対応になるでしょう。

mrboxを実行するとhelpが出力されます。

$mrbox 
Usage: mrbox [mrbox options] [command] [mrbox options] -- [mruby option]
Author:Kouichi Nakanishi(keizo042)
mruby binary sandbox manager.

example:
---

$mrbox build --name hello
$mrbox mruby --name hello -- -e 'puts "Hello mrbox World!"'

---

At first, you must execute 'mrbox setup'. 
by default, it use default mruby repository.
if you specifiy option '--name', download mruby repo into local  and manage it as this name.

options
--file (-f)     ---   using specific mruby's build_config.rb
--name (-n)     ---   nameing mruby binary, it use when build,clean,mruby.mirb,mrbc

subcommands:
build -- build mruby binary.
clean -- clean up mruby repo
help -- print help and version
init -- intialize local mrbox sandbox
show -- show your named mruby binaries
setup -- setup global mrbox's mruby sandbox
update -- update mruby repo
mruby -- use mruby
mirb -- use mirb
mrbc -- use mrbc
mruby_strip -- use mruby-strip
edit -- edit build_config.rb
config -- config mrbox

使い方は上記のexampleにあるように、--nameでインストールするmrubyにネームタグをつけて、
--fileで使用するbuild_config.rbを指定します。
実行するときは、--nameでつけたネームタグを用いてそのmrubyリポジトリを呼び出しbuild,update,executeなどを行います。
オプションは -- で区切られ、--以前はmrbox, -- よりあとは実行するバイナリに渡されます。

mrbox setupコマンドはデフォルトのmrubyレポジトリを落としてくるなどの環境のイニシャライズで、
~/,mrboxディレクトリになんやかんやを用意するコマンドです。
今はディレクトリを掘っているだけですが、今後の機能拡張に伴いいろいろぶち込むことを想定しています。

$mrbox setup
$mrbox build --name hello
$mrbox mruby --name hello -- -e 'puts "Hello mrbox World!"'

一度buildしたプロジェクトのbuild_config.rbはもう一度build --name helloなどをするか

$mrbox edit --name hello

とすることで編集が可能です。
mrbox edit helloでも編集出来るようにもしようと考えています。

TODO

  • stdin/out/errの取り回し
  • bovi/mgem対応
  • gembox対応
  • mrbox configコマンド実装
  • mrbox initコマンド実装
  • mrbox cleanをmrbox rmにrenameして改めてmrbox cleanを実装
  • サブコマンドオプション整備
  • Windows対応

bovi/mgemを呼び出してmgem configのbuild_config.rbを用いることや、mruby-onig-regexpの関係でビルドから外しているWindowsビルド整備や、
internalで呼び出しているrm -rf などをmrubyに移植したり(mruby-fileutilsの整備が必要)、gitコマンドを叩いているところをmruby-gitとしてexportしたりなどを考えています。

とりあえず困っていたmrubyバイナリの管理は解消されていい感じになりました。
mruby advent calendarの記事でも宣言したように2019/1/31をめどにv1.0.0をリリースし破壊的変更を控えるようにします。
それまではインターフェースをガンガン破壊的に変更していくつもりなので人柱力が高いひとのご協力をお願いします。