roboforum.ru

boez писал(а):Обе этих возможности в TCP/IP есть, но для реализации удлиннителя уарта особо не нужны. Надо подумать, что может быть еще кроме уарта, к чему может понадобиться такая функциональность. Датчики?

Реализация сервера может быть полезна. Как пример - ПК обладает какой-то информацией, которая должна быть доступна роботам. Приложение на ПК ничего не должно знать о том, скольким роботам это нужно, какие у них адреса и т.д. Клиент подключился, получил/скинул иформацию - все счастливы.

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

С разделением между канальным и сетевым уровнями тоже не все так просто выходит, если подумать. Ведь uIP у нас Ethernet-заголовки сам формирует, так что наш пакетный драйвер должен с ними уметь работать. И при этом поддерживать Wi-Fi-подобную CSMA/CA схему. Так что вырисовывается чуть более сложная схема:

РобоРФ: Приложение - РобоРФ-транспорт+сеть - РобоРФ-канальный - драйвер СС2500.
TCP/IP: Приложение - uIP - Ethernet-канальный - драйвер СС2500

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

Либо забить на любую совместимость с uIP и делать канальный+сетевой уровень вместе - там можно будет на байтах сэкономить, к примеру запихнув все - канальные, сетевые и транспортные флаги в 1 байт.

Возможно, что добиваться совместимости на уровне приложения и не стоит (а может и правда стоит) - нужно оценить, чего нам это будет стоить по ресурсам.

пока ехал домой в голову пришли мысли о том, что интерфейс транспортны-приложение тоже надо откуда-то "слизать". у тех же gsm модемов (у которых зашит стек) как с этим? (EdGull должен быть очень в курсе). Может применить что-то из этой области?

С разделением между канальным и сетевым уровнями тоже не все так просто выходит, если подумать. Ведь uIP у нас Ethernet-заголовки сам формирует, так что наш пакетный драйвер должен с ними уметь работать. И при этом поддерживать Wi-Fi-подобную CSMA/CA схему. Так что вырисовывается чуть более сложная схема:

имхо проще обрезать uIP и забирать у него ip пакеты а не ethernet кадры. тупо забирать их до обвешивания mac уровнем.

нифига я не в курсе, мы юзаем GSM-модемы как обычные

как обычные это как?

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

Можно. И по IP-адресу сразу вести адресацию в канале связи, а ARP выкинуть. Или второй вариант - ввести свои однобайтные канальные адреса и свой ARP. Между прочим, с маршрутизацией в uIP тоже не особо. Форвардинга пакетов кажется нету вообще.

Можно. И по IP-адресу сразу вести адресацию в канале связи, а ARP выкинуть.

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

Или второй вариант - ввести свои однобайтные канальные адреса и свой ARP.

чего-то мне это не нравится. маленький протокол от этого пострадает а ip не выиграет.

Между прочим, с маршрутизацией в uIP тоже не особо.

а нам и не надо. я маршрутизацию рассматриваю только в больших IP сетях. между собой вполне должно хватить коммутации.

Мне почему-то кажется, что в результате получится что-то или монстрообразное, или совсем ущербное. Может все-таки (TCP/)IP отдельно, а протокол попроще - отдельно?

Может все-таки (TCP/)IP отдельно, а протокол попроще - отдельно?

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

Добавлено спустя 4 минуты 48 секунд:
я даже так скажу.

физический и канальный разрабатываются для ЖЕЛЕЗА. будь то плата такая или плата сякая, сетевой и транспортный применяется в зависимости от задач (уже без оглядки на железо. абстрагировались мы от него на канальном) а связь с этим на уровне приложения уже прозрачна и одинакова или во всяком случае однотипна. и не учитывает ни наши требования к достоверности передачи (это на транспортном) или среды передачи (это на канальном).

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

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

Предлагаю начать с канального + интерфейс с физическим.

Добавлено спустя 5 минут 33 секунды:
Заведите новую тему наверно. Здесь пока конкретики мало, так что отделять вроде нечего.

blindman писал(а):Я почему просил описать свое видение протоколов по уровням более формально - тогда можно будет определить интерфейсы и прикинуть предварительно насколько удобно будет ими пользоваться и какого уровня совместимости можно достичь. А пока все разбросано, одни общие слова - лично мне например трудно картину в целом увидеть.

Будет. Пишу. Уже почти страницу написал.

frig писал(а):я даже так скажу.

физический и канальный разрабатываются для ЖЕЛЕЗА. будь то плата такая или плата сякая, сетевой и транспортный применяется в зависимости от задач (уже без оглядки на железо. абстрагировались мы от него на канальном) а связь с этим на уровне приложения уже прозрачна и одинакова или во всяком случае однотипна. и не учитывает ни наши требования к достоверности передачи (это на транспортном) или среды передачи (это на канальном).

Да тут дело в том, что канальный уровень, реализующий CSMA/CA по типу вайфая, сразу автоматом реализует некоторые функции сетевого (адресация) и транспортного (подтверждение) - без них просто не получается. И поэтому выходит, что верхние уровни для мелкого протокола просто вырождаются.

Ладно, пока мысль идет в таком направлении: разрабатывается простой канальный уровень с минимальным заголовком, применимый для общей полудуплексной среды передачи. Это может быть радиоканал, ИК или УЗ. Он определяется форматом пакета и процедурами обмена. Формат допускает возможность отправки сообщений других протоколов, к примеру IP.

Также формат пакета определяет поля для двух транспортных протоколов семейства RoboRF, условно названных TCP и UDP, любые совпадения с реальными названиями случайны Сетевые адреса сетевого уровня совпадают с аппаратными адресами канального уровня, задаются одним байтом и могут принимать значения от 1 до 254, 0 и 255 зарезервируем под широковещание. Такое совпадение упраздняет ARP как класс. Подтверждение доставки на канальном уровне оставляет для TCP только 3 задачи - адресацию портов в пределах одного устройства, управление инициацией/завершением соединения и повторную передачу неудачных пакетов. Для UDP - вообще только первое.

Да тут дело в том, что канальный уровень, реализующий CSMA/CA по типу вайфая, сразу автоматом реализует некоторые функции сетевого (адресация) и транспортного (подтверждение) - без них просто не получается. И поэтому выходит, что верхние уровни для мелкого протокола просто вырождаются.

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

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

имхо вся схема должна выглядеть примерно так

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

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

frig писал(а): не надо нам гарантий доставки на канальном уровне. упразднить как класс. пускай канальный занимается только доступом к среде. адресацию можно ВСЮ положить на сетевой а гарантии доставки - на транспортный.

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

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

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

Я вообще-то предполагал следующую схему реализации CSMA/CA:

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

Такая схема в Wi-Fi находится полностью на канальном уровне, насколько я помню. И если нам захочется IP поверх RRF - то это у нас тоже будет канальным уровнем. Если сетевым мы считаем IP.

Конечно можно это обозвать транспортно-сетевым уровнем. А канальным - пакетный драйвер, который только и умеет передавать, принимать пакет и канал слушать. Но тогда на канальном уровне у нас никакого Collision Avoidance не будет. И напрямую к IP его не прилепишь.