Ооо, имел дело с кодом MeshConnex. Даже занимался созданием PoC на его базе.

За Олифера спасибо. А можете подробнее объяснить, как вы построите STA — AP — STA — STA — AP — STA?
STA — AP — STA — это понятно, а как STA — STA? Клиенты умеют общаться друг с другом будучи в разных BSS и следуя WiFi спецификации?
Насколько я понимаю WiFi Direct, если вы используете его, то передачу данных на MAC уровне WiFi Direct вам не даст. И следующий уровень, на котором узлы будут видны друг другу — это сетевой.

И то, что я имел ввиду насчет звезды в WiFi Direct. Насколько я понимаю, вы не сможете построить топологию типа: STA — AP — STA — STA — AP -STA, так же как STA — AP — STA — AP — STA так, что все устройства смогут общаться на L2 уровне. Т. е. весь роутинг у вас будет на сетевом уровне.

Ок, а как вы будете гарантировать, что не замкнете устройства в два кольца, которые несоединены друг с другом, и, таким образом так и не собрав все узлы в одну сеть? Вам нужен будет алгоритм, который будет разруливать то, каким образом два узла должны подключаться. Плюс никакой динамики. Если у вас узел в цепочке пропадает, то очень вероятно, что вам придется перестроить всю отвалившуюся сеть.

А иначе я тогда не понимаю, причем здесь WiFi и 11s, если на L3 можно и так меш построить. Только что уровень проблем другой. И всех прелестей беспроводного соединения не получить.

Дело не в этом. Дело в том, что то, что делает WiFi Direct называется топологией звезда.
Другая проблема, что даже если вы возьмете чипы, поддерживающие AP и STA (Client) одновременно, вы все равно не сможете построить меш, т. к. вы сможете иметь соединение только с одним клиентом, и с одной AP, даже если в вашей зоне видимости есть еще устройства, с которыми вы можете работать.

WiFi Direct это чуть более чем не меш. WiFi Direct сохраняет роли стандартной спеки WiFi добавляя расширения поверх инфраструктурного режима. Иначе говоря, WiFi Direct не даст вам несколько соединений в роли STA. А построить меш топологию используя только AP и STA роли, даже если они поддерживаются одновременно, вы не сможете.

Какой же там может быть mesh, если, судя по спецификации, нет поддержки ни AdHoc, ни WDS, ни 11s?

И снова вовзращаемся к:

…
Интервьюер: Да, я понимаю, но не могли бы вы подсказать мне, сколько у вас опыта именно с коричневыми? Ну, плюс-минус.
Плотник: Я действительно понятия не имею. С того момента, как дом построен, меня не волнует, в какой цвет его покрасят. Может, шесть месяцев?
Интервьюер: Шесть месяцев? Вообще-то мы ищем кого-нибудь с гораздо большим опытом коричневого, но позвольте мне задать вам ещё несколько вопросов.
Плотник: Ладно. Но, знаете, покраска — это покраска.
...

А как же uClinux? Он как раз работает там, где нет MMU.

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

Да. Но экономия еще и в отсутствии постоянной связи между устройствами. Если не разединять, то разрядится оно довально быстро. Все профайлы Low Energy передают минимальное количество данных. Т.е. файлы погонять то можно, но батарея действительно быстро разрядится.

Реально хватает на год — два, если использовать раз в день. Гуглим Bluetooth Low Energy или читаем комменты выше :)

Можно погуглить Nordic Key Fob. Они на Bluetooth Low Energy как раз, т.е. тоже самое, что на видео. Только, соответственно, нужен телефон (ноутбук, etc) с Bluetooth Low Energy и реализованным Proximity профайлом.

Это профайл Proximity. И он довольно банален.

Low Energy вполне себе работает и на расстоянии 10ти метров. Проблема лишь в том, что фактически угадать расстояние не получится, т.к. все зависит как от передатчиков, так и от помех между ними. Вообще, учитывая еще, что RSSI никогда не показывает стабильное значение, а «плавает» в каком-то диапазоне, то вы можете быть свидетелем того, что ваш пуль сам перемещается по комнате.

Упс, не туда ответил. См. ответ ниже.

Ха. Во-первых, как вы определите порядок линковки через «Use local libs» ?) Если бы все это работало, проблем бы не было.

А во-вторых, если не ошибаюсь, Ministro как раз загружает библиотеки в папку с именем программы, что как бы уже означает, что для каждой программы — свои библиотеки.

Ох и натерпелись мы с этим Necessitas когда-то в своем проекте :)
Начнем с того, что там не был собран QtDBus (dbus в андроиде, как известно, есть). Собрать — собрали, а загрузить не можем: Ministro то не знает о нашей библиотеке. Давай смотреть, что же Ministro делает, когда загружает библиотеки. Оказалось, что он грузит xml-файл с сервера Necessitas`а, в котором описаны Qt-библиотеки, путь до них на сервере, их версии, размер, и… порядок загрузки! Этим порядком загрузки определяется и порядок линковки библиотек. В общем, &lttrollface&gt делать было нечего, подняли мы свой Apache &lt/trollface&gt. Создали такую же структуру каталогов, как на сервере. Пропатчили xml-файл, добавив туда QtDBus. Начинаем загружать с помощью Ministro библиотеки… падает на линковке, т.к., если не ошибаюсь, он линкует их как только загрузил библиотеку. Тогда-то мы и узнали что порядок загрузки определяет порядок линковки.

Этот упоротый Ministro еще и заново загружает каждый раз библиотеки после перезаливки приложения. Почему нельзя было, например, с apk класть эти библиотеки? Ведь Qt-программа, собранная Necessitas`ом — это та же библиотека.

А еще, если нужно консольное/демон Qt-приложение под андроид, то можно просто исправить Makefile, генерируемый Necessitas, чтобы собиралась не библиотека, а готовый бинарник.

Еще из интересно, что встретилось при работе с Necessitas: часто вылетает сообщение «QEventDispatcherUNIX: internal error, wakeUps.testAndSetRelease(1, 0) failed!». И еще довольно странно ведет себя QWaitCondition: похоже, не всегда отрабатывает wakeAll().

Напомнило: