io::Read が実装されてて任意のバイト列を自由に詰めておけるような物体が標準ライブラリにないかどうか気になって Read の implementation を VSCode で見てみたら VecDeque<u8, A> が使えそう（名前からして・A は Allocator トレイトを満たせばよい）。しかも VecDeque<u8, A> は io::Write も実装しているので、rustls::Stream<'a, C, T> の T: 'a + Read + Write に適合している！最高。でもおそらく VecDeque<u8, A> の Write の実装がそのまま rustls の中で呼び出されてしまうと、本来は client または server 側から送られてきた TLS payload を Read で読んでほしいために VecDeque に一旦 ebpf-afw のアプリケーションコードがそのバイト列を格納してくれるだけなはずなのに、その payload に対して「自分が接続してたならばこういった TLS payload を相手に返すだろう」と rustls が考えたものがそのまま Write のメソッドを介して書き込まれてしまいそうなので意図したものとは異なった動作をしてしまいそうな気がする。
std::io::Write を満たす inner trait
バスの中で書いていたら保存がずっと失敗するようになり、リロードをかけたら Cloudflare tunnel の再認証画面になって書いた内容が吹っ飛んだ 😇
Write を外側の構造体が実装するときには実装の中身を空にしてしまえばよいという結論が得られた。それと、スレッドローカルに HashMap<5tuple, Stream> を持ちたいとも思った。
実験してみてわかったが、rustls::Stream.new() で socket の mutable reference を渡す必要があるので、それ以降から socket にデータを入れようとした際に多重な mutable reference になってしまい動かなくなってしまう。
MockTcpStream による io::Write の実装を見ればわかる通り、mutable reference は実際の挙動からすると不要なものとなるので剥がしたいが、そのためには rustls::Stream の実装そのものを変更する必要が出てくるように思う。rustls 側で client_random を生成してくると思われるが、それを妨げて外部から流し込むためのインターフェイスとその仕組みを入れてあげる必要がある。これは master_secret についてもそう。もう、すでに rustls に対しては様々な改変を入れることがわかっているので Stream のメソッドのシグネチャに入っている &mut を & に変えてしまってもよいかもしれない。
……と思ったが、Write にかかわらず Read 自体がそもそも &mut を要求する可能性があることに気づいた。実際、Read の read() のシグネチャを見てみると &mut self, ... から始まっている……。MPSC but for single thread のような存在がほしい。要は、ちゃんと Mutex を用意して MockTcpSocket を囲ってあげなければいけなさそう。さらに、そのような socket を扱うため、MutexGuard を取得してから read() に準ずる操作を行わせるための Stream も実装しなければならない。https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
impetushttps://stackoverflow.com/questions/73840520/what-is-the-difference-between-stdsyncmutex-vs-tokiosyncmutex
ebpf-afw では tokio::sync::Mutex を使っているが、rustls の変更を加えるときには std::sync::Mutex でもいいかなと思ったし、それでもよさそうなことがわかった（仮にわざわざ tokio のバージョンを採用しようとすると rustls の依存として tokio を入れる必要が出てきて面倒）。MutexGuard の inner をちゃんと取るためには明示的に Deref または DerefMut のメソッドを呼んであげればよい。
VRC
ベルセルク https://younganimal.com/series/f68f676b354d4neuroscience