roboforum.ru

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

А - надо будет глянуть на зигбишный CSMA/CA. Он вроде чуток другой, чем в вайфае.

А нам надо, чтобы транспорт RRF работал с чем угодно?

аха.

1. передающий - принимающему: "хочу передать". Уже на этом этапе нужен адрес принимающего. Иначе кто ответит?
2. принимающий - передающему: "передавай" или "нефиг"
3. передающий - принимающему: сам пакет
4. принимающий - передающему: "принял", "повтори" или "ничего не выйд

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

альтернативные варианты

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

гарантии доставки выносить еще и на канальный уровень смысла не вижу.


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

короче чувствую я не дождусь в этой жизни обычного радиоудлиннителя усарта...

короче чувствую я не дождусь в этой жизни обычного радиоудлиннителя усарта...

не бояйся. тебе ж не нужен абы какой удлинитель? тебе ж хороший нужен, чтобы работал?

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

пошлятина какая-то получилась

frig писал(а):альтернативные варианты

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

гарантии доставки выносить еще и на канальный уровень смысла не вижу.


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

Коллизии не будет если "хочу передавать" будет состоять из "Адрес передатчика + Адрес приемника + хочу передавать"
2. принимающий - передающему: Адрес приемника +Адрес передатчика+ "передавай" или Адрес приемника +Адрес передатчика+"нефиг"
......
ну в общем кадр состоит из /адрес передающего/=1 байт, /адрес принимающего/=1 байт, команда или данные

Коллизии не будет если "хочу передавать" будет состоять из "Адрес передатчика + Адрес приемника + хочу передавать"

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

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

Что думаете об этом: [[en:MACAW]] ?
Подробнее здесь : http://pdos.csail.mit.edu/decouto/paper ... avan94.pdf

это то самое о чем говорит boez. мне не нравится ввиду того, что нужна адресация на этом уровне и эти переговоры сожрут довольно много полезной полосы, которой и так много.

А разве в классической модели OSI нет адресации на канальном уровне?

а почитай. реально нам эта адресация не нужна. только дублирование функций а значит избыточный вес пакетов и "отъедание" полосы служебкой.

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

На канальном уровне - только контроль доступа к среде. Канальный уровень не занимается адресацией ни в каком виде. Контроль доступа осуществляется следующим образом : узел ждет освобождения среды (отсутствие несущей), передает пакет (возможно предваряемый коротким пакетом "хочу передавать"), переходит в режим приема. Так?

Так?

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

так еще и приоритеты можно расставить на доступ к среде.

Добавлено спустя 3 минуты 55 секунд:
могу диаграммку нарисовать для наглядности. и алгоритм набросать.

То есть все-таки еще одно переключение передача/прием/передача, чтобы иметь возможность услышать "чужой" длинный пакет.

Так в чем тогда будет разница:

включение передачи
RTS
включение приема
прослушивание канала (ищем "хвост" чужого пакета RTS)
включение передачи
DATA
включение приема

включение передачи
RTS
включение приема
CTS
включение передачи
DATA
включение приема
ACK

Всего один короткий пакет, плюс адреса (1-байтные скорее всего)

frig писал(а):могу диаграммку нарисовать для наглядности. и алгоритм набросать.

Было бы неплохо.

Добавлено спустя 1 минуту 55 секунд:
Кстати схема с RTS/CTS позволяет хоть как-то решить проблему скрытого узла.

----------------
Now playing: Андрей Макаревич - Лица

Вот диаграмма при адресах в пакетах и подтверждениях. объясню почему так.

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


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


теперь здесь. адреса нет. это скорее не запрос на передачу а выкрик "Я передаю!" состоять может быть из произвольной последовательности единиц и нулей. Побеждает тот у кого длиннее. Его даже не надо разбирать как пакет а только воспринимать наличие несущей.

Потом переключаемся и буквально 1 байт слушаем эфир. если у нас выходит самый длинный - начинаем передачу. подтверждения, буфера - все уровнями выше.

Добавлено спустя 8 минут 40 секунд:
а еще надо учитывать, что разница может и не большая относительно, но нагрузка на МК будет выше во первых, а во вторых все переговоры о скоростях о мощностях и о всем другом тоже будут идти поверх такого метода доступа к среде. т.е. потери будут больше, чем просто на передаче данных.