Progressive

PeerCast の再実装の進捗どうですかという話

PeerCast

Twitter でぼちぼちつぶやいているが、 PeerCast の諸々を Rust で再実装するということをやっている。普段仕事の通勤の移動時間のうちの半分程はバスに座っていられるので、その時間を PeerCast の再実装の時間に充てていた。ところが最近のご時世で在宅勤務ができるようになったため、移動時間がまるまる自由時間になってしまった。その自由時間に何をしていたかは昨日までのブログ記事の通りだ。おかげで作業がさっぱり進まなくなってしまった。

とりあえず基本的なデータ構造の解析やハンドシェイクなどはできるようになった。そこからリレーに加わるための諸々を組んでいるところ。しかしそこから先が中々進まない。ここまでのところは本家の実装を読んで仕様を整理することができていたが、その作業が止まってしまった。本家コードは読み解くのが非常に困難なので、実際の挙動から実装していくこととしたが、これがうまく回っていない。どうしたもんかな。このままだと間違いなく開発は中断するだろう。 現に今もコード書くより Minecraft をやりたい気持ちのほうが強いし

実装面でもここまでで使っている I/O ライブラリ tokio に由来する懸念がある。 TCP のデータ待受と書き出しを同時にすることができないのだ。どうも tokio の中でも今使用している async/await 方式はまだ API が安定していないようで、このあたりをうまく表現できていないようなのだ。 I/O に関しては別に実装が進んでいる async-std というものもあるので、こちらに乗り換えるかどうか悩みどころだ。

Rust を書くこと自体は楽しい。配信などでも何度かこの表現をしているが、コードを書くこと自体が「高難度パズルゲーム」なのだ。コンパイルが通るなら大体うまく動く状態になっているということになるので、コンパイルが通ることと成功体験とが密接な関係になっている。すると、コンパイルが通る事自体が気持ちいいと感じるのだ。なんだこれ。多分 Rust が愛される言語である所以はこういうところにもあるんじゃなかろうか。

一旦コード整理して本家の実装をもっかい整理するのが良いんだろうか。レガシーコードを解析する王道は テストコードを書いたり試行リファクタをしたりすること だけど、 C++ だしなあ。難しい。そして tokio から async-std への移行も検討したい。このあたり進めるなら一旦成果物に固めるのが良さそうだが、特に成果となる物は現時点では作れないのでテストコードを充実させるあたりだろうか。それでもって何処までできているかを明示することにもなるし。


© 2002-2020, Built with Gatsby