Спасибо!

Спасибо всем просветившим меня!

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

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

Прикрутить формирователь фреймов из SLIP - это круто, но не хочется.
Хочется по простому...

Моя следующая идея.

Берем два совета. В один пишем блок данных. В другой - ASCII заголовок
пакета. (выделение в потоке начала заголовка - через выделенный
символ). Принимающая сторона выгребает все из сокета данных, и кидает
в ответ по контрольному сокету, что пакет считан.

Далее процесс повторяется.

Как эта идея?

Я для этой цели использовал простой "самодельный" протокол:
-----
02 байта тип пакета
02 байта длина данных
хх Данные
-----
Пакеты садятся в буффер, первый пакет "выдёргивается", всё остальное сдвигается к началу + проверки.
На первый взгляд, довольно нудно парсить, но как показала практика способ удобный.
Позволяет легко разделять "слипшиеся" пакеты (TCP NODELAY не везде работает).
Проверяется всего один сокет (всего один вызов select())

А можно ещё проще, опять по одному сокету:
На каждую посылку принимать подтверждение (длина и тип естественно в заголовке), тупо! но действенно.

Сообщение отредактировал nazim - Jan 15 2006, 19:24

Думал я об этом. Вроде препятствий нет - TCP должен по идее гарантировать:
* доставку байтов
* сохранениех их порядка
* отсутствие дупов

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

Приняли как описано - засунули в структуру (данные апроксимируем массивом максимальной длины). "Провернули" буфер указателей.

Обработчики пакетов с другой стороны "проворачивают буфер" и разбираются с содержимым структуры.

Один трабл - синхронность запуска и остановки процессов. В варианте разных машин это може быть не так примитивно.

Вероятно, надо сделать гибрид. Ввести все таки контрольный сокет, по нему буквально однобатный обмен: типа приняли 0x55 - вычитали сокет до конца, выкинули эти данные, обресетили state machine и начали все сначала. В ответ по контрольному сокету можно 0xАА кинуть - типа обресетился, готов.

За идею!

Обалдеть.

А можно узнать, от чего? Если я какое ламерство написал - поянилите, плиз! Все-таки, сокеты сохраняют границы пакетов или нет? Я в литературе пока информации о сохранении границ не нашел.

Вообще-то для обеспечения прозрачности передаваемых данных существует такое дело как байтстаффинг: договариваются о некотором управляющем символе, присутствие которого означает, что следующий за ним символ - команда. Если следующий символ - также управляющий символ, значит эти два символа интерпретируются как один символ данных равный управляющему символу. Немного сумбурно написал, но смысл такой:
0x10 0x12 - управляющий символ 0x10, команда 0x12(смысл которой например начало или конец пакета)
0x10 0x10 - данные 0x10
В качестве управляющего символа естественно лучше всего брать наименее вероятный в потоке данных.
Собственно нечто подобное в SLIP и реализовано.

Ну так вот при перемещении фрагмента кадра в кольцевой буфер этот байтстаффинг и делается.
При этом кольцевой буфер является именно [b]кольцевым буфером символов[b], а не кольцевым буфером кадров/пакетов.

Для обработки пакетов при копировании из буфера сокетов в буфер символов создается управляющая структура типа


которая ставится в очередь и после обрабатывается в фоновом потоке.

Удачи!

1. Да я много написал. Потом оставил одно слово.

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

2. По конкретному вопросу о сохранении (если естественно не SOCK_STREAM )- сохраняют,
для этого и делалось. Отвечать за отсутствие ГРУБЕЙШИХ ошибок в многочисленных реализациях я естественно не могу, но СОХРАНЯЮТ.
3. Использование TCP уровня взамодействия в пределах одной машины перебор. TCP имеет смысл при работе именно черт знает через что (этому определению безхозный интернет полностью
соответствует ). Плата за "гарантированую доставку" _полная_ потеря реального времени и потеря произвольного (но порядка десятков килобайт) количества пакетов до получения хоть какого-то
намека на развал соединения. В принципе вышеописанное не является "родовым пятном", просто
реализации в 'больших системах' (линукс, вынь) давно плюют на обработку ошибок транспортного уровня и ограничиваются (в лучшем случае) только фиксацией факта для статистики. Производители
железок тоже пошли по этому (пусть с проблемами протоколы высокого уровня разбираются) пути.
Правда такая ситуация породила и рынок альтернативных стеков и самодельных надстроек
над UDP или RAW. Лично я пользуюсь для встроенных систем самообжитым IP стеком с обработкой
аппаратных ошибок, что при работе в _локальной_ сети с _правильным_ железом хабов/свичей
позволяет без потерь доставлять UDP датаграммы. При необходимости более жесткого
реального времени, большей простоты (со строны контроллера) и меньшей непредсказуемости конкретной реализации IP стека и драйверов на "больших" машинах - пользуюсь самодельным протоколом на фрейме IEEE 802.3 по мотивам IEEE 802.2. Со стороны "больших" реализуется как надстройка над RAW Socket.

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

Но я несколько опечалился. Неужели разные "BSD-Like" стеки так сильно отличаются друг от друга? Все-таки сохранять или не сохранять границы юзеровских пакетов - это фундаментальное отличие. Я думал в этой области все давно вылизано, и царит полнейшая гармония. Весь кайф испортился.

Я НЕ ВСТРЕЧАЛ и ДУМАЮ НЕ ВСТРЕЧУ такого безобразия - это ФУНДАМЕНТ. Все мои замечания по этому поводу относятся только к тому что где-то кто-то что-то видел/слышал и по этой причине решил
добавить в механизм еще свою спичечку привязав ее веревочкой...
Для _высокоуровневых_ протоколов в массовых серьезных операционках - можете считать, что царит гармония. За поведение многочисленых "микроконтроллерных" стеков сделанных кем-то для использования в каких-то определеных условиях при использовании изделия в других РАЗНООБРАЗНЫХ условиях отвечать просто НЕВОЗМОЖНО.
Ну и еще замечание - если собираетесь базироваться на на *NIX ообразной открытой операционке для чего либо не являющегося настольной машиной с иксами - обратите свой взор в сторону FreeBSD.
Ее по крайней мере делает поименованый управляемый коллектив.

Это не Ваши знания :-( они разрознены и противоречивы местами. Дальше что? Монетку кидать?
На здравый смысл уповать? На книжку ссылаться? Только практика критерий истины.
И еще Ваш подход (это я базируясь на надбюдениях за другими темами) к делу поражает немалым размахом. Такая организация дела несомненно работает и по своему эффективна, но в БОЛЬШИХ
коллективах (ну начиная с полусотни разработчиков и прочего персонала на проект) с изрядным финансированием, для содержания оных. Это Ваш случай? Если нет, то все Ваши усилия на поддержание "установленного порядка" сожрут все ресурсы разработчиков.

Эта мысли меня уже посещала. Но стремно:
* спецов по BSD очень мало
* книжек тоже, хотя несколько книжек я уже утащил
* книжек по NetBSD вообще нет (я не нашел). По иее это самый что ни на есть embedded BSD
* хочется иметь ту же самую платфому на писюке и embedded девайсе. Хотя бы пока я учусь.

Потом, очень даже возможно, будут перепрыгивать на BSD.

1. На умении выуживать знания из противоречивых данных и мнений я всю свою сознательную жизнь живу. Надеюсь, эта функция моего BIOS меня не подведет и сейчас. Главное, чтобы подсознание отработало. Я не будут завтра кодить сокеты. Но через пару недель, когда я этим займусь, у меня уже будет некая система реперных точек, которя сработает в нужный момент. Опытный факт, что мне это сэкономит массу времени и сил.

2. Замах большой, это так. И колектива 50 девелоперов (вместе с бюджетом) тоже нет. Но с годами я дозрел до практики downgrade. Т.е. когда задача осмысливается целиком, начиная с верхнего уровня. Потом я рисую схему сущностей проекта (листов 30 А4), и делаю безжалостную кастрацию всей красоты, оставив ГЛАВНОЕ, и "крючки" для навешивания всего остального.

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

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

3. Дьявол таится в деталях. Я не сомневаюсь в этом! И проблем будет масса! Лично для меня важно понимать, что именно надо делать (иметь некое объектно-ориентированное мышление применительно к целевой задаче, когда важны методы , а вот конкретный "экземпляр класса" выстраивается по ситуации), а с самим деланием потихоньку разберемся. Мир не без добрых людей.

Спасибо Вам за Ваши ценнейшие замечания!

1. Ну по большому счету их под Линукс мало, если не считать спецов уровня "инсталляторов
Windows". Массовые программисты разницы ПРОСТО НЕ ПОЧУВСТВУЮТ. Ну разбираться в
железках/драйверочках (впрочем помнится с железом проблем к Вас не предвидится) в BSD
заметно приятнее.
2. Ну книжки... С простыми вопросами и без них разберетесь, а готового рецепта выхода из сложной
ситуации Вы в них не найдете - НЕ ДЛЯ ЭТОГО ИХ ПИШУТ. А исходники BSD много читабельнее,
нежели то болото в которое превратились многочиленные Линуксы.
3. А может просто возьмете "кувалду побольше" (помнится я уже намекал на SOM-144, например)
и получите без проблем с портированием (и сопровождением оного) почти одинаковые системы. Причем, если Вы полагаете, что если на десктопе и на какой-нибудь железке с ARM9 будет одна операционка по причине того, что там и там она спекулирует раскрученным словечком Линукс, то это совсем не так
:-(
Сколько там контроллеров с 'линуксом' в год предполагается выбрасывать на рынок?

Конечно, оси на дектопе и контроллере будет разные. Но, если у них одинаковые версии ядра, то базовые интерфейсы, по идее, должны совпадать. Я собственно, на это и надеюсь.

SOM-144 - привлекательная вещь, я про них очень хорошо помню, и цены не очень безумные. Но я пока на нашел их Industrial, и, боюсь, цены там как раз будут неразумные.

Для прототипов, где мне будут нужны x86, буду использовать это
http://www.icop.com.tw/products_category.asp?CategoryID=2

По моим оценками Intel PXA270 600 Мгц мне должно хватить на ближайщие проекты на несколько лет вперед. Но хочется иметь позможность "спуска вниз", посему попробую все-таки целевой осью сделать eCos. Собственно, будет использован аналог SOM-144 от
http://www.toradex.com/e/Products_Colibri_..._Pentium_M.html

Контроллеров будет от 100 до 1к в год - как дело пойдет.

Ядро по исходникам изучать пока не готов

1-2 Тут есть много вариантов.
3. Синхронизация происходит ценой потери _одного_ неполного, на момент подключения к каналу, фрейма.

Сообщение отредактировал Harbour - Jan 16 2006, 09:39

Это если Вы всегда, постоянно ищите помянутое 4x байтовое магическое значение и тем самым
начисто исключаете его наличие в потоке для других целей. Но мне помнится там у Вас еще и размер
поминался? Из чего я сделал вывод, что внутри фрейма указанного размера магическое значение
НЕ ищется.. А иначе зачем размер еше гонять?

Считаем:
1. Потеряли байтик - потеряли первый фрейм
2. Не нашли в ожидаемом месте магическое значение - начинаем искать - теряем второй фрейм
3. Встретилось нештатное магическое значение - продолжаем терять...

Естественно, ценой хранения предыдущего фрейма можно выкрутиться с п.2, но цена выкрутиться
будет еще и всплеск затрат времени в ранее гладком алгоритме (а байтики то об этом не знают
и продолжают идти..., что в некоторых случаях (речь не про сокеты) может потребовать еще и буфера для сырого потока). В случае c байт/бит стаффингом всегда имеем простой алгоритм с абсолютно предсказуемыми максимальными затратами времени на выделение фрейма и отсутствие необходимости
в дополнительных буферах для запоминания чего-либо на случай проблем. Может оказаться немаловажным и тот факт, что имеем ВСЕГДА одинаково БЕЗ ИСКЛЮЧЕНИЙ работающий алгоритм, а
в случае с волшебными словами еще придется писать и тестировать ветки поведения
при ошибках. Это конечно не "бином Ньютона", но ошибиться можно :-( а оно это надо?