a on Nostr: ...

引用のやつ、想定してたライブラリ関数使う形ではうまくいかなくて絶望感だったのだけど、Client to Client （他方がListenするのではなく、相互に接続先アドレスを指定する形）でも SCTPストリームが張れることが試したら分かったので、そこいら使った絡め手でラッパー書いて、同じようなI/Fで使えるようなものは作れそうな見込みが立った。

しかし、ちょいと書いて動くものになるかと思ってたら、結構規模が大きくなってきたので、もっとカッチリやらないと破綻しそうな気がしてきた。

あと、（まだ同一マシン上で動くからマシだけど）テストケースが素直に書けないのでどうしようかなー感。
リグレッション用に書いておかないと後で死にそうなんだよなあ。
分散システムはこういうあたりの面倒さもつらいところである。

Pythonあたりで複数プロセス（ピア・ノード）を起動して各々のstdoutをチェックするようなものでも書くかなああ。
（探せば、その手のテストフレームワークとかあるかな）

quoting
note1sl0…4qwx

こやつ (※)で、オーバレイ上でListenしてるノードが複数ノードを相手にできるよう苦心してコード書いて、動作確認を始めたところ、

※: https://github.com/ryogrid/gossip-overlay/tree/4479d343c9425e3b6c770e03f7e0460d6637dc29

実装で利用している pion/sctp というライブラリが以下のようなエラーを出力しており、

sctp ERROR: 2023/11/24 22:40:06 Failed to handle chunk: todo: handle Init when in state: Established

そもそもpion/sctp が想定する形での利用をサポートしてないようだと分かり、困ったなあ、となっているなう。

とはいえ、SCTPの実装と一口にいっても、RFCのどこまでに対応しているかは個々の実装次第なんですよね。

あとは、そもそもpionというやつは WebRTC実装（のためのライブラリ？）をこしらえることを目的としたプロジェクトらしく、リポジトリ名を省略すると、webrtc, datachannel、dtls、turn、ice とか軒並み実装していて、私が使わせてもろてる sctp のライブラリもその中の一つだったりする。

んで、WebRTCだと1対1のdatachannelが1つ張れれば、最低限良いはずで、そこからするとpion/sctpのサポート範囲が現状のそれでもおかしくはないんかな、と思ったりしました。
（メディア用の通信路は別ポートで張ればよい？）