search

nttcom / moq-wasm

MIT License
17 stars 0 forks source link

Publish/SubscribeされたTrackのデータの持ち方について考える #55

Closed tetter27 closed 3 weeks ago

tetter27 commented 2 months ago

SUBSCRIBE_OKを受け取ったサーバはSUBSCRIBEリクエストを送信したclientのidと、Track毎にユニークに生成されるTrack IDを保持する必要があります。

現TrackManagerはTrack IDで管理する方針ではないと思うので、現TrackManagerをPublishedTrackManagerに名称変更し、 あらたにSubscribedTrackManagerを定義してTrack IDを管理する方針を考えました。

この構成で進めて問題なさそうでしょうか。

Untitled

yuki-uchida commented 2 months ago

これの実現方法はかなり沢山ある上にどれもメリデメあるのでデータの持ち方を検討するというタスクで一回切った方がいいかもしれませんね。

例えばTrackManagerでTrackIDも管理するようにするというのも一案かなと思います。そして、Track情報のなかにSubscriberのリストも追加していくようにすると、新たなManagerが不要になります。

他にも、

などあるかなと思います。データ構造の定義はかなり難しいので、それぞれのメリデメを比較して選びたいですね。

tetter27 commented 2 months ago

なるほど、ありがとうございます！ ではこのissueはデータの持ち方を検討するタイトルへ変更します。

直近はスピード重視でいきたいので、取り急ぎ図の形で実装進めます。 もしも問題など見つかれば修正入れる方針で行きます。

tetter27 commented 2 months ago

すみません、色々考えてみるとこれが一番楽そうですね、、

例えばTrackManagerでTrackIDも管理するようにするというのも一案かなと思います。そして、Track情報のなかにSubscriberのリストも追加していくようにすると、新たなManagerが不要になります。

こちらで進めてみます。

yuki-uchida commented 2 months ago

大きくは異論ないんですが、スピード重視だから設計を疎かにするのは一般的にはアンチパターンだと思います。 何故なら、設計の質が良ければ開発スピードが出て、設計の質が悪ければ開発スピードが出ないからです。

t_wadaさんの「質とスピード」というドンピシャなスライドがあるのでこちらを参考にしてください。個人的にも質を追求した結果スピードが生まれるという経験の方が多いです https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition?slide=33

今回特定の設計をこの場で選ぶのであれば、「スピード重視」というロジックではなく「３つの方法を比較検討した上で、このタイミングにおいてはAが最善だと判断した。これ以上は分からない点も多くコスパがよくないので検討を打ち切る」というロジックにした方がいいかなと思います

yuki-uchida commented 2 months ago

僕はtetterさんが「TrackManagerでTrackIDも管理するようにする」が一番楽だと考えられた理由もなんとなくしか分かってないので、これが一番楽だと思った理由を書いてもらって検討の結論としてもらいたいです。

このまま進んだら1,2週間後には「なんで他の選択肢もあったのにこれを選んだんだ？」って疑問に思いながら実装することになりそうだなと思います。そしたら「再設計した方がいいのか？」って思いながら実装することになって、結果として実装スピードが落ちそうです。

tetter27 commented 2 months ago

ありがとうございます。 この辺り、実際の開発の考え方が頭から抜けていたので、実例交えたご意見いただけてとても参考になります。

僕はtetterさんが「TrackManagerでTrackIDも管理するようにする」が一番楽だと考えられた理由もなんとなくしか分かってないので、これが一番楽だと思った理由を書いてもらって検討の結論としてもらいたいです。

これは消去法的な判断をしました。 まず、PublishedTrackManagerとSubscribedTrackManagerに分けると2つのDBを同時に管理することになるので、整合性を保つのが少し面倒だと思います。MOQTにはPub <- Track <- Subという依存関係があるので、Pub、Track、Subは紐づいた状態で管理してPubが消えたら必ずTrack, Subも消えるように作っておくのが安全だと判断しました。 また、最終的にはRDBを使用するのが良いかもしれないですが、手軽に使用できなくなってしまうのでプロトタイピング段階としてはtoo muchに感じました。

yuki-uchida commented 1 month ago

すいません、返信してませんでしたがLGTMです。 OBJECTの送信の際にforループ回さなきゃいけない問題について、早速ここの設計の弱点が出た形になりますが、検索方法を複数に対応させようとするとRDBがやはり綺麗ですね。

とはいえ、プロトタイピングとしてtoo muchだという意見には僕も賛成なので、多少の検索性の問題は目を瞑ってよいかなと思います