[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]

[Burichan] [Foliant] [Futaba] [Greenhell] [Gurochan] [Photon] - [Home] [Manage] [Archive]

[Return]
Posting mode: Reply
Leave these fields empty (spam trap):
Name
Link
Subject
Comment
File
Verification
Password (for post and file deletion)
  • Supported file types are: GIF, JPG, PDF, PNG
  • Maximum file size allowed is 20480 KB.
  • Images greater than 200x200 pixels will be thumbnailed.

File: 1398567889684.jpg -(5794 B, 166x157) Thumbnail displayed, click image for full size.
5794 No.103929  

Как можно решить проблему перегрузки центральных узлов в mesh-сетях?

>> No.103930  

Использовать multipath routing, чтобы при перегрузке задействовались также незагруженные пути.

>> No.103931  

>>103930
Как определить что альтернативный путь не загружен еще больше?

>> No.103932  

>>103929
Да.

>> No.103947  

Хранить в памяти загруженность соседних узлов же.
Правда, от bottleneck'ов это едва ли спасёт.

>> No.103948  

>>103947

> Хранить в памяти загруженность соседних узлов же.

Как тогда узел должен разруливать ситуацию, когда трафик на незагруженный узел пришел от единственного незагруженного соседа?

>> No.103956  

>>103948
Вычеркнуть цепочку отправителей пакета из списка получателей?
Вообще, в меш-сетях отправитель должен как-то знать маршрут(ы) до получателя. Посмотри практические реализации (та же ネツクク)

>> No.103957  

>>103956

> Вычеркнуть цепочку отправителей пакета из списка получателей?

Это ведь никак не помешает источнику продолжать отправлять пакеты тем же маршрутом.

> Вообще, в меш-сетях отправитель должен как-то знать маршрут(ы) до получателя. Посмотри практические реализации (та же ネツクク)

В ネツクク эта проблема никак не решена и загрузка узлов игнорируется.



Delete Post []
Password

[/b/] [/d/] [/tu/] [/a/] [/ph/] [/wa/] [/cg/] [/t/] [/p/]