Цель - реализовать демон, ориентированный на пользователя, который будет настраивать mesh-сеть для улучшения ее масштабируемости и надежности. В будущем возможно использование адаптации для уменьшения потребления энергии.

Демон получает статистику от драйвера или другого подходящего источника и настраивает параметры сети по заданным заранее схемам.

Идея: сделать частоту multicast-рассылок зависящей от плотности сети. Для этого нужно определить, через что определять плотность и как ее измерять.

В плотной сети увеличивать периодичность multicast/broadcast рассылок.

Периодичность рассылок определяет компромисс между покрытием сети и затрачиваемым временем. Редкие рассылки дойдут до удаленных узлов, но они могут застопорить/перегрузить сеть собой (это долго живущие пакеты) и необходимостью их постоянно пересылать ( непонятный момент). В плотной сети велика вероятность получения кадра при частой рассылке, так как узлы ближе расположены друг к другу и число пересылок в такой сети больше.

Возможным недостатком такой политики может стать обособление отдельных удаленных узлов, которые станут меньше участвовать в работе сети. Необходима проверка, действительно ли эти узлы будут испытывать трудности и в какой степени (если да).

Варианты механизма нахождения активных соседей:

1. просмотр таблицы маршрутов и расчет числа обратных маршрутов ( вероятно время окончания срока действия маршрута станет адаптивным и тогда оно должно будет влиять на данный алгоритм);
2. число обнаруженных за определенный интервал кадров-маячков ( требует встраивания в прошивку);
3. число адресов удаленных источников или пересылающих узлов, обнаруженных за определенный интервал ( требует встраивания в прошивку).

Если узел работает на батарее, он должен акцентировать (показывать) худшие метрики.

Механизм нахождения маршрутов должен в первую очередь обрабатывать узлы, питающиеся от аккумулятора и т.п., что поможет продлить время работы батареи.

Возможный недостаток - появление в маршруте лишних переходов (хопов).

Частота, с которой ХО передает управляющий трафик (запросы/ответы специального устройства для сбора информации), может быть уменьшена без ущерба функциональности, что значительно сэкономит время передачи.

добавить подробное описание

Из-за ограниченных ресурсов памяти в ХО встроен простой алгоритм подсчета ошибок передачи кадров, который уменьшает уровень передачи, если заданное число последовательных кадров потеряется, и, аналогично, увеличивает этот показатель, когда заданное число кадров успешно пересылаются. Проблема заключается в том, что когда пакеты теряются из-за перегрузки сети, уменьшение показателя передач сделает ситуацию еще хуже.

добавить подробное описание

Когда сервис присутствия решает, что ХО находится в mesh-сети, он использует mDNS для опубликования и получения информации о присутствии. Когда сервис решает, что в сети есть сервер, он переключается с mDNS- на XMPP-сервер. Сервис присутствия должен выдавать решение, агностическое (независимое?) от наличия или отсутствия сервера.

Улучшить mesh через использование 802.11n PHY, который обеспечивает скорость передачи данных до 600 Мб. Улучшения на MAC-уровне в .11n включают агрегирование кадров, что может быть полезно для сети при передаче коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.

Заставить mesh использовать 802.11n PHY, который обеспечивает скорость до 600 Мбит/с. Улучшения в .11 MAC включают также возможность агрегирования кадров, что полезно при передаче множества коротких кадров. В использовании .11n MAC для mesh-сети есть вопросы, требующие решения в рабочей группе по стандартам.

Передача между mesh клиентом и mesh порталом испытывает проблемы: XO laptop сам приписывает себе адрес локальной подсети - 169.254; когда он находит портал, тот в свою очередь приписывает XO закрытый адрес подсети - 172.16. Лучше было бы разбить подсеть 169.254.х.х на 3 подсети для использования на каждом канале (1,6,11). Порталы mesh-сети распространяют данные о своем присутствии в сети через mDNS. Предполагается, что управление сетью в Linux уже поддерживает такую конфигурацию, но возможно Avahi потребует дополнительной настройки для работы с нестандартной локальной подсетью.