いろいろあった。いや、いろいろはないな……。
Erlang & Elixir Fest 2018に行ってみた。どっちも全然知らんけど。 ErlangはRTMPの参考になんかのメディアサーバーのソースを読んだくらい。
知らんわりにはなかなか楽しめた。 前半は事例紹介が主で、最初はなるほどなと思うものの、同じようなのがいくつも続いたんで飽きてしまった。 後半は技術的なところが多かったような気はするが、まあそんなに高度な話は無かったみたいだ。 俺は全然知らんかったから良かったけど、普段使ってる人は物足りなかったりしなかったんかな？
なんかまだ使われ始めたばっかりで、使ってるよーという以上の話にはあんまならなかった感じ。 これから盛り上がってくといいですね。
知ってる人にはそんな目新しい話でもないだろうけど、PubSubの実装の話は面白かった。
ニコニコ内部のメディア中継サーバは興味深い、というかPeerCastとやってることは同じなんで(P2Pのアルゴリズムは素朴なPeerCastなんかよりもっとまともなやつだが)、やっぱそうなるよなあと思いつつ聞いてた。
PeerCastStationもErlangとかElixirで書き直すか！とか思いつつ聞いてたが、まあ現実的にはないわな。いろいろあってC#になってるわけだし、まあしばらくはC#のままのつもりだわ1。
それでも作り的に参考になるところはいくつもあったので取り入れていきたい。Phoenixの(?)Supervisorてやつは良さそうね。.NETでもTaskの管理するようなやつ欲しいなという気はしてたが、やっぱそういうのあるんだ。そして再起動まで勝手にやってくれるのは確かにうれしい。
技術書典5の募集が発表されたようだ。 うーん、前も書いたけど今度の参加はどうしたもんかなぁ。 本よりプログラム書きたい。 でも一度申し込まなかったらもう二度とやらん気もするなぁ。
しかし今回は会場だいぶでかいぽいね。広さ3倍ですよ3倍。都合の良い場所がなかなか無い的なこと言ってたんでまだ同じ場所かと思ってたけど、実はもう新しい場所取ってたんか。 前回は倍率1.3だか1.4だかで、そんな落ちる人も居るのに俺なんかが出てるのも申し訳ないなあと思ってたんだけど、今度は落ちそうもないし申し訳ない気持ちになることもないかも。 とはいえ新刊全く無しというのもなんなので、出るなら薄くても何か書きたいしなあ……。
ユーザーがWindowsメインなんでWindowsで動かしやすくて、でも他のプラットフォームでも比較的簡単に入るランタイム入れれば動いて、そして配布やビルドがめんどいのでどこでもだいたい同一バイナリが動く、ってのが第一。第二には俺がそこそこ書けて(Java環境はさっぱりわからん)、他人でもいじれそうな言語(F#とかRubyは微妙だな)というところでC#になってるんで……。 ↩
新バージョンをリリースしたところ、いくつか不具合報告が上がってきたので対応した。
PeCaRecorderというツールで、ツール終了時にいっしょにPeerCastStation(とかPeerCast)本体も終了するオプションがあるんだが、それで終了しなくなってしまったとのこと。
PeerCastには-killというオプションをつけて起動すると既存のインスタンスを終了する機能があるんだが、PeerCastStationもそれを実装してて、でもオプション周りちょっといじったから動かなくなったのかな？と思った。
確認してみると-killオプションは動いてるなあ。詳しく状況を聞いてみるが使い方は間違ってないし、前のバージョンに戻したら上手く終了するようになったとのことなんで、やっぱ今のバージョンでの問題か。
手元でPeCaRecorderを試してみると、2回に1回は終了してくれるという変な動作をしている。プロセスを見てると、どうもPeCaRecorder終了時にPeerCastStation.exeのプロセスを一つTerminateProcessかなんかで強制的にぶっころしてるような感じだ！
アップデートのために起動プロセスからメインプロセスを分離して立ち上げるようにしたんだが、起動プロセスだけ殺されてメインプロセスは普通に動いちゃってるので死なないように見えたようだ。まあ実際死んでない。
TerminateProcessで殺されるのをトラップしてメインプロセスを終了させればいいだけなんだが、TerminateProcessは強制終了なのでトラップできねー。これはどうしようもないのでは？
と思ったが、メインプロセス側が親の起動プロセスを監視して、死んだら終了すればいいのか。かなりトリッキーなことになりそうで嫌だなぁと思いつつ書いたが、べつにトリッキーなことにもならんし普通に書けた。
メインプロセス起動時に、親プロセスのPIDを渡してもらって、そのプロセスを監視すればいいだけだった。
WindowsとUnix系両対応が不安だったが、Process.Exitedイベントは普通に動くしなんら問題なかったんで無事解決した。
他のプロセスを強制終了してくるのは行儀的にどうかと思うが、親プロセスが死んだらおとなしくいっしょに死んでいくというのはやっておくべきことではあったと思うしよしとしよう。
DebianでIPv6アドレスで接続待ち受けができないという報告が来た。
どうもDualStackな接続待ち受けがされようとして、IPv6の::0にbindしようとするとIPv4の0.0.0.0にもbindされようとしてかちあってるっぽい？
そんな動きすんのかよ……。
setsockoptでIPV6_V6ONLYを1にすれば良さげとのこと。てか.NETからも素直に設定できるようになってるんだが、Windowsだと標準で1なんで気付かなかったっぽい。macOSでも気付かなかったんで標準で1なのかな？LinuxとかFreeBSDでは標準0だったりするみたい。
まあ0の理由はないんで明示的にIPv6Onlyを設定しておくことにした。
しかしこの機能かなり微妙だと思うんだけど、中途半端に余計なことしないでほしいな……。
こっちは上手く再現できる環境がすぐには作れなかったんで確認お願いしたけど、上手くいってりゃまたリリースしたいところ。