roboforum.ru

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

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

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

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

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

----------------
Now playing: Pink Floyd - Shine On You Crazy Diamond

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

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

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

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

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

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

Это искусственное условие. Да и помещения разные бывают, как и сценарии применения протоколов связи.

frig писал(а):RTS/CTS/ACK тоже её не решает.
если есть 3 узла A B и С, причем а слышит b а b слышит с, но а не слышит с, то при передаче кадра от а к b с не сможет идентифицировать передачу кадра и пошлет свой rts, который приведет к коллизии в передаче a и b.

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

----------------
Now playing: Pink Floyd - Shine On You Crazy Diamond

ато у 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 добавятся повторы по таймауту. Все это будет закреплено в протоколе как опции, которые каши не просят если их не юзать.

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

В случае скрытых узлов она все же понадежнее, потому wifi и работает со скрытыми узлами.

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

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

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

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

это будет не слишком большим усложнением?

А станция в режиме raw - тупая и работает по алгоритму frig.

ну хорошо хоть станция... а вообще не такая уж и тупая. работать будет быстрее

boez, я так понял, что у вас оно все на достаточно высоком уровне готовности уже? можно прекращаться копья ломать? все уже решено?

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

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

Таймауты будут сильно зависеть от физического уровня.

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

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

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

frig писал(а):

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

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

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

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

А вообще raw полезен - тем, что в нем возможны бродкасты. Я там где-то заикался насчет бродкаст адресов, потом подумал - для них нужно будет модифицировать схему обмена, потому что CTS и ACK посылать некому - нет единого адресата. И только сейчас понял, что без CTS и ACK у нас получается как раз raw-обмен

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

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

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

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

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

угу.

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

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

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

Покажу. Но скорее всего завтра.

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

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