Firezone、boringtunを捨ててRust製WireGuard実装「sanstun」を公開
Sanstun: A sans-IO, parallel-friendly WireGuard implementation in Rust
Firezoneは、2年以上にわたり70件以上のパッチを当てて使ってきたCloudflareのboringtunを置き換えるべく、sans-IO設計のWireGuard実装sanstunを公開した。IOや時間、乱数といった副作用を状態から切り離し、型によってレート制限の適用漏れやトンネルの誤配送をコンパイル時に防ぐ。暗号処理を別スレッドへ渡せるAPIにより、1280バイトのパケットでは暗号化のうち管理処理はわずか2%にとどまる。
パケットサイズが1280バイトの場合、新しいパケットを暗号化する際の管理処理の割合はわずか2%にすぎない。実際の暗号化を別スレッドに移せば、45倍以上の高速化の可能性が示唆される。
HNでの議論
19- Twey
すべて順調に進んでいたが、次の文を読むまでは
> この設計は関数カラーリングのような問題も回避し、Rustの所有権ルールともうまく調和します。
AsyncはI/Oではない。I/Oに使うことはできるが、それは純粋で決定的な状態機械を、論理的な流れをバラバラの遷移に散らかすのではなく一箇所に保ちながら書く方法にすぎない。
たとえasyncのフローを明示的な状態機械に手動でコンパイルすることを選んだとしても、依然として「関数カラーリング」（別名タイピング）に対処しなければならない。複数の状態遷移をまたぐフロー（その間、他の遷移を介して状態の他の無関係な部分が更新される可能性もある）は、今や一連の状態遷移として書き直さなければならず、ブロッキング関数から呼び出すことはできない。むしろ、すべての状態機械を`async`なしで書き直すことは、関数カラーリングの「問題」を悪化させる。なぜなら、複数遷移のフローは通常の関数とはさらに異なったものになるからだ。
- monocasa
いいね、これは基本的に私がRustでプロトコル実装を設計する方法と同じだ。
はるかにテストしやすく、大部分をasyncとブロッキングI/Oの間で共有でき、依存関係（stdとcoreを除く）でunsafeを完全に禁止するのがずっと簡単になる、などなど。
- temp0826
Mullvadもboringtunから独自の実装をスピンオフした（gotatunと呼ばれている[0]）