транспорт для потока данных

[Алексей++]

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

Вопрос : не изобрёл ли я случайно велосипед (описание ниже)? Какие ещё способы есть для данной задачи (разделение пакетов в потоке) ?

суть транспорта:
примерно 1/8 (на самом деле - чуточку больше) бит потока выделяется под маркеры границ, 7/8 - данные.

пусть длина пакета == Len

1) Начало пакета покажет байт транспорта с 1 в седьмом бите:
1xxxxxxx ,
 где xxxxxxx - это, скажем, версия транспорта (или что угодно вообще, хоть идентификатор приёмника пакета)

2)
Len/7 == количество семёрок байтов в пакете.

Если Len/7 >0 , то для каждую семёрку данных преобразуем в 8 байт транспорта:

Код:

   0         1        2        3        4        5        6
Aaaaaaaa Bbbbbbbb Cccccccc Dddddddd Eeeeeeee Ffffffff Gggggggg

->
   0         1        2        3        4        5        6       7
0aaaaaaa 0bbbbbbb 0ccccccc 0ddddddd 0eeeeeee 0fffffff 0ggggggg 0GFEDCBA

нули в седьмых битах показывают, что это данные.

3)
далее, если Len%7 >0 , то также раскидываем остаточные байты:

Код:

   0         1        2
Aaaaaaaa Bbbbbbbb Cccccccc

->
   0         1        2        3
0aaaaaaa 0bbbbbbb 0ccccccc 00000CBA

Извлечение данных из транспорта описывать по моему не нужно ))

[Sla]

Зачем изобретать велосипед?
Есть открытый для всех модбас
А потом - а если нужно в данных передать и старший бит?

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

Для модбаса Синхронизацией  служит время отсутствия передачи (3.5 - 4 байта)

[RXL]

Леш, а цель какая?

[Алексей++]

Слав,

А потом - а если нужно в данных передать и старший бит?

легко - это делается итак , передаётся всё один к одному

что есть модбаса ? И да, у меня время передачи по барабану

Ром, цель -
1) передать пакеты по хрен знает какого качества каналу по протоколу TCP/IP ,
2) распознать в программе-получателе, что это для неё данные (хотя бы по транспорту)
3) возможность чтения потока кусками - обрабатываться будут только полностью полученные пакеты

[McZim]

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

А что мешает без изобретения протокола передавать данные? TCP/IP не позволяет? (даже если хрен знает какой канал связи). ИМХО, обычное клиент-серверное приложение.

[RXL]

1. TCP обеспечивает тебе доставку потока данных. Понятия пакет нету. Непринятых данных тоже нет, но возможен обрыв соединения.
2. IP+PORT = адрес программы.
3. см. п.1

Леш, толи ты большущий лисопед изобретаешь, либо я не понимаю тебя.

[Алексей++]

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

[Вахмурка]

 Ну например первые два байта будут показывать длинну пакета. Потом идут байты данных, контрольная сумма и т. д. Только это зачем?

[Алексей++]

Вахмурка, хе хе хе, а ежели это был не размер, а невменяемый мусор ? Что дальше делать бы стал ?

[Вахмурка]

  Алексей1153++, в TCP давно всё придумано. Получив норамальный пакет клиент отправляет источнику пакет потверждения. Если сточник не получил пакет потверждения, то передача пакета повторяется. Иначе надёжная передача вообще не могла бы быть. Так же можно сделать и сдесь.

[Алексей++]

не канает, я работаю не напрямую с TCP же , класс мне отдаёт просто поток данных, он сам с сетевыми делами работает

[Алексей++]

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

[RXL]

Леш, подсистема TCP за тебя все это делает.

[Dimka]

да только в сокет всё приходит в виде потока (а ещё и передать могут кусками на той стороне). Как отделить пакеты ?

А зачем? На входе некий поток, на выходе - тоже. Транспортировка, контроль доставки и кромсание на IP-пакеты "прозрачны" для передаваемого потока (в том числе автоматически исправляются потери в пути, доставка разными маршрутами, перепутывание порядка пакетов и т.д.). Случиться может только одно - полный выход канала связи из строя. Но и на этот случай на уровне IP предполагается наличие разных маршрутов доставки в обход проблемных участков (если сеть построена с учётом таких проблем).

И вообще TCP/IP разрабатывался с расчётом на работу в условиях ядерной войны .

Если же у тебя на входе в поток пишут чёрт знает что, то проблема тут отнюдь не в транспорте.

[Алексей++]

как-то всё у вас всех просто выходит А у меня проблема была - отделить пакеты друг от друга. Теперь нету проблемы

[Sla]

Я понимаю проблемы Лешки
Есть некий девайс, возможно тормознутый, и мозгов  у него мало, и возможностей для организации канала. Девайс может поддерживать, например, только последовательную передачу. О каком тисипи может быть речь?
Вот и лиспед появился. Со временем, я думаю, эта проблема исчезнет, и все устаканится и завернется в тисипи, но отладить нужно сейчас. Леха! дерзай!

[Алексей++]

дык с прибором то только так и поступаем , самое смешное - именно передача по сети: использую MFC-шный класс CAsyncSocket , в виртуальном методе OnReceive (событие - что то пришло) считываю полученные данные через Receive . Если не применять транспорт, а пакеты - разной длины, то всегда натыкаюсь на ситуацию, когда считана только часть какого то пакета (остальное ещё ожидает считывания). А какой там нафик подсчёт CRC (а про длиннновые байты - вообще отдельная тема), если неизвестен конец пакета ? Анализировать это всё слишком накладно, а транспорт чётко делит пакеты

[McZim]

Sla, дык Лехе нужно передать данные по протоколу тисипиАЙпи.

[Алексей++]

McZim, итак по нему передаётся, всё замечательно доходит от одного компа к другому, проблема то не в этом )))

вот и ощущение такое, что у меня одного такая проблема, видимо я что то упускаю из вида ?

[x77]

Вахмурка, хе хе хе, а ежели это был не размер, а невменяемый мусор ? Что дальше делать бы стал ?

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

[Алексей++]

легко:
1) если я ожидаю маркер начала пакета (1 в 7 бите) , я начну принимать пакет (при чём, остальные семь битов должны быть обычно версии, скажем это число 5. Но, ладно, пусть даже там не только версия) Далее должны идти только нули в седьмых битах.
2) если пакет уже был начат, то очередной маркер начала говорит о том, что паке считан - отдаём на обработку
--
а в случае с байтами размера по любому пришлось бы сначала все N байт скачать , чтобы понять, что это косяк. А если это была ошибка ? А если внутри этого блока были 1000 правильных коротких сообщений ?

[zubr]

Когда то я делал подобное (городил свой протокол обмена) - таковы были требования заказчика.
Протокол был простой:
1. Постоянная длина пакета, которую знает 2 стороны.
2. В заголовке пакета (8 байт) контрольная сумма и номер пакета.
3. Отправляющая сторона посылает пакет и ждет подтверждения (короткого пакета Ok)

[Алексей++]

когда длина постоянная - было бы проще, но тут длина от 10 байт до 65к+

[Sla]

Алексей1153++, я че подумал, фигня все это...
работай малыми пакетами - и не будет лисапета...

Единственно, что интересно в твоем протоколе, так это независимость от скорости канала, но тогда у тебя в канале должен гулять ТОЛЬКО один пакет

[Алексей++]

Слав,

работай малыми пакетами

низя ( одна из передающих сторон - железяки, которые или нельзя или трудно менять

но тогда у тебя в канале должен гулять ТОЛЬКО один пакет

- пояснение требуется. Пакетов уже не один, их много, в чём ты видишь ограничение ?

[zubr]

когда длина постоянная - было бы проще, но тут длина от 10 байт до 65к+

Тогда ставь на конец пакета спецсимвол. Если внутри пакета попадаются спецсимволы удваивай их. Если количество символов нечетное - конец пакета.
По спецсимволу определил пакет, прочитал заголовок, проверил контрольную сумму.

[Алексей++]

zubr, возможно, это тоже решение.
Остаётся только проблема с мусором. А ещё - какой бы символ не был выбран за маркер, существует вероятнось, что этого символа в данных может оказаться много Как тут быть ?

[Алексей++]

ну и контроль по версиям нельзя сразу сделать, кстати

[Алексей++]

zubr. хотя, в принципе, если данные сжаты, скажем, LZ, то значения байтов распределены примерно одинаково, то есть вероятность любого символа на 256 байт == около 1/256 . Тогда блок увеличится в среднем на 100/128 == 0,78 % Надо будет попробовать как-нибудь и статистику пособирать

Но, опять же, вкусный мне контроль по версиям не получится - придётся считывать и раскодировать данные сначала

[Алексей++]

в общем, выбор стоит так:
1) предложенное Зубром (удвоение маркера) - стОит использовать, когда какой то байт заведомо реже других встречается. Менять для каждого пакета это значение нельзя (в принципе можно, но это затраты времени вычисления наименее частого символа, затем посылка "установочного" пакета, который задаст новый маркер, после чего приёмная сторона будет пользоваться новым маркером). "Универсальным" такой протокол не будет - кпд у него непредсказуемо меняется от 100% до 50%
2) если пользовать транспорт с маркером в седьмом бите, то кпд всегда 87,5% или чуть поменьше (зависит от средней длины пакета)

люблю, когда всё равномерно работает Мне больше нравится №2 , хотя он и сложнее, чем №1