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

[Алексей++]

а, между прочим, среднее для 100 и 50 == 75 , что меньше постоянного 87,5 , о как

[zubr]

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

[Алексей++]

каким образом она уменьшится то )

[zubr]

Ну комбинация к примеру из 3-х байт abc в пакете будет встречаться реже чем байт а

[Алексей++]

ммм, а если пакеты - всего по 3 байта ? Трафик растёт вдвое... Короче, понятно, надо всё время от конкретной ситуёвини плясать

[Алексей++]

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

пока что реализовал свой новый протокол (который в начале темы)

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

[sss]

Алексей1153++, вот как я реализую принцип целостности пакетов.

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

1. Подключается совершенно левый клиент и начинает посылать бессмысленные (в контексте приема) данные. Можешь поверить это легко вычисляется. Единственное что нужно предусмотреть - максимально возможный разумный предел размера одного собранного пакета.

2. Разрыв при приеме длины. Т.е. если длина пакета представляет собой 4 байта, то в какой то момент ты получаешь не всю длину, только часть. Но это то же поправимо. 

[Алексей++]

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

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

разрыв вычислится по CRC в уже принятом и раскрытом пакете, но это не сложнее, чем сначала ждать все 0x01afde байт

[sss]

Не понял. Фиксированно - размер , переменно - данные. Какое еще CRC? TCP соединение закроется еще в ядре при разрыве... Понятно дело с UDP...

Еще раз:

Код:

struct NET_BLOB
{
  LONG32          lBlobSize;
  BYTE               Data[0];
};

Какие проблемы с передачей разных пакетов? То, что поток неразрывен берет на себя TCP. Чего еще городить то? Есть проблемы с разрезкой lBlobSize. Но они решаются в месте приема...

[Алексей++]

Не понял. Фиксированно - размер , переменно - данные.

а в случае, когда летит мусор ?

[Вад]

Алексей1153++, а какая разница, искать хвост или не искать, если в мусоре может попасться "пакет" хоть на стотыщмегабайт, где совершенно случайно в начале есть маркер начала, и в конце - маркер конца?

[sss]

Какой мусор в TCP !!! Откуда берется?

[Вад]

Поддерживаю sss, у нас тоже так был реализован протокол: сначала структура с размером и типом пакета, затем уже бинарные данные, которые все знают, как парсить. А лучшая защита от мусора - авторизация сессии Если же кто-то, замышляющий худое, твой протокол знает, то, соответственно, на уровне протокола хитрить бессмысленно.

[Алексей++]

Какой мусор в TCP !!! Откуда берется?

легко , примеры:

1) беру и посылаю мусор
2) другая версия программы
3) ошибка в версии программы клиента

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

это всё тоже есть, но внутри транспорта

[sss]

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

[Алексей++]

sss, для меня задача - не тратить много времени на анализ транспорта, он максимально простой и с чёткими границами. А всё остальное в программе выполняется быстро. Может , поэтому у нас разногласия После написания транспорта мне стало очень удобно работать в программе с передачей данных по сети , и я не понимаю, почему , тебе, к примеру, это всё так не нравится )

[sss]

Да почему не нравиться. Я считаю, что чем проще, тем лучше.

Ты вот 3 примера указал:

1) беру и посылаю мусор
2) другая версия программы
3) ошибка в версии программы клиента

Это ошибки логики твоей программы, а не сетевой среды. При этом задача транспорта - доставка, а не поиск ошибок в программе. Если это не так, ты запросто получаешь множество версий транспорта для каждого приложения.

[Алексей++]

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

[zubr]

Насчет мусора - простой пример:
Обмен данными между 2-мя модемами по обычной телефонной линии с плохой связью. Здесь мусором будут посторонние шумы линии.

[sss]

zubr, TCP считает CRC