ルーティングアルゴリズムの改良がイマイチだった

WebRTCのやTCPのように、コネクション型の通信経路を使う場合、特定のノードに接続が集中すると、そのノードのリソースが不足したり、負荷が上がってしまう。例えば、macOS sierraではユーザがopenできるディスクリプタの数は256に制限されているため、1ノードに64コネクションも接続すると25%も圧迫することになる。そのため、各ノードへの接続は可能な限り分散することが望ましいと考える。※WebRTCの通信はUDP上にSCTPを実装しているため、TCPほどディスクリプタを消費しないと思うが、経路情報などを個別に持つためメモリや計算負荷はTCPより高くなるのでは？という考えからも、接続は分散したい。

新しいルーティングアルゴリズムを実装してみたものの、ノードの多い・少ない、通信が偏っているか・分散しているかによって、接続が集中してしまうことがわかった。ノードが多く通信が偏っていないようなシミュレーション環境であれば、こうはならなかったのだろうが、自分は実用可能なプログラムを作りたいので、これではいただけない。

シミュレーションや計算で正しいと思われていたアルゴリズムを実装しても、現実の制約などから生じた微妙な差により、シミュレーション通りの動きにならないことを体感。（と言って良いものか、単純に考えが浅いのかもしれない）

収穫は、コネクション型通信を利用したノードが等価なルーティングアルゴリズムにおいて、通信経路の確立は互いに合意がなければならない(片方の合意が無ければ、切断してしまう)と考えていたが、ある一定のルールにより合意がなくとも経路の確立を決定できそうなことかな。