roboforum.ru

И на каждое подтверждение - новый "выкрик" и прослушка. В то время как с RTS/CTS/ACK знаем что эфир свободен.

это только канальный уровень. tcp, который тоже должен будет работать поверх этого канального уровня только будет все дублировать.

Добавлено спустя 1 минуту 18 секунд:
а еще бывают протоколы в которых вообще подтверждения доставки нет. и они тоже могут и будут востребованы и работать.

Каким образом будет решаться или хотя бы ослабляться проблема скрытого узла?

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

RTS/CTS/ACK тоже её не решает.

Добавлено спустя 1 минуту 45 секунд:
если есть 3 узла A B и С, причем а слышит b а b слышит с, но а не слышит с, то при передаче кадра от а к b с не сможет идентифицировать передачу кадра и пошлет свой rts, который приведет к коллизии в передаче a и b.

Добавлено спустя 3 минуты 38 секунд:
wifi, вон, со скрытыми узлами работает.. причем часто в сети ВСЕ узлы скрытые.
Проблема есть, но она не так критична и имхо жертвовать производительностью в нормальных условиях ради частичного решения редко возникающей проблемы не стоит.

ато у C есть возможность услышать CTS от B - таким образом вероятность коллизии снижается.

услышал он cts... сколько ждать для посылки своего rts? максимальный размер кадра?
все станет еще хуже, если рассматривать всю эту работу с таймаутами.

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

а нужно-ли?

Добавлено спустя 28 минут 13 секунд:
на счет того, что нельзя побороть так это не так. можно. но только используя маркерный доступ а это еще бОльший гимор.

Да - именно о MACAW я и говорю. В случае скрытых узлов она все же понадежнее, потому wifi и работает со скрытыми узлами. В твоей схеме при передаче от узла 1 к 2 (пусть есть слышимость 1-2 и 2-3, но нет 1-3) ничто не мешает узлу 3 бахнуть передачу RTS в любой момент и испортить этим пакет данных. А в MACAW такое возможно только на начальном этапе, но не во время передачи пакета данных. Хотя исходно я постулировал что на скрытые узлы мы забиваем, я почему-то считал, что MACAW с этой проблемой не борется - но раз борется, это же хорошо.

Количество переключений "прием-передача" или одинаковое, или всего на одну передачу больше. Но зато мы "бесплатно" получаем контроль доставки (с гарантией доставки вопрос отдельный).

А вообще есть еще идея. Решение, известное с древних времен - надо взять младенца и разрубить его пополам . Протокол у нас любительский? Так добавим ему исследовательских возможностей. Разрешим работу в двух режимах: MACAW и raw. У меня там как раз еще 2 неиспользованных ID пакета осталось - будет RTS-raw и DATA-raw. Безадресные.

Последовательности такие:
MACAW: RTS-CTS-DATA-ACK
raw: RTS-raw DATA-raw

Станция в режиме MACAW умеет понимать raw пакеты. И при приеме RTS-raw ждет пакета DATA-raw и принимает его. А при приеме RTS - отправляет CTS, ну и далее по схеме. А станция в режиме raw - тупая и работает по алгоритму frig. Я думаю, что при добавлении случайных задержек перед передачей система будет работоспособна даже в смешанном режиме (ессно станции raw могут общаться только друг с другом).

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

В общем постараюсь сегодня-завтра дописать и дорисовать автоматы состояний для протокола - и вот тогда создам отдельную тему и выложу.

Далеко не все проработано, формат пакета более-менее, хотя я его теперь малость поменяю , описан автомат состояний для MACAW, но там пробел пока в вопросах таймаутов и backoff.

На работе совсем звери - работать заставляют...

услышал он cts... сколько ждать для посылки своего rts? максимальный размер кадра?

сам и отвечаю. это можно исправить, если в rts и cts передавать размер передаваемого пакета с данными. но это все еще больше усложнит.

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

Переговоры - которые?

да хотябы о скорости обмена. у нас то условия будут не одинаковы (а скорее всего даже разнится между двумя станциями) и скорости будут везде разные.

так вот переговоры надо вести на минимальной скорости, чтобы даже с минимальным уровнем сигнала их можно было вести. иначе "отпадут" клиенты у которых уровень ниже некоторого или, не дай бог, максимального.

Добавлено спустя 1 минуту 17 секунд:

А вообще raw полезен - тем, что в нем возможны бродкасты.

угу.

Добавлено спустя 8 минут 25 секунд:

формат пакета более-менее, хотя я его теперь малость поменяю

покажи хоть чего есть...