TCP_NODELAY , To be or not to be?

[Хрен]

Доброго времени всем!
Ситуация у меня следующая:
Есть клиент, который передаёт небольшие (до 128 байт) пакеты данных разной длины по протоколу TCP. И есть сервер, которые эти данные принимает.
Дело в том, что пакеты на клиенте шифруются, каждый отдельно. Следовательно, для их успешной расшифровки необходимо их принимать так же отдельно. Но коварный (в нашем случае) алгоритм Нейгла не даёт принимать все пакеты отдельно, и приходят они иногда склеенными, разорванными и не подлежащими разбиению на правильные куски.
Я подумываю о TCP_NODELAY, но на довольно многих форумах встречал высказывания, которые гласили, что TCP_NODELAY, дескать, ересь, и программистам, которые его используют, вечная анафема =)

Кто что посоветовать могёт по этому поводу? Протокол на UDP менять нельзя. И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =)

Заранее спасибо

[Хрен]

Т.е. единственный вариант, получается, SOCK_RAW и парсить?

[Alexandoros]

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

[Хрен]

Цитата

И разделителей или других псевдозаголовков тоже ставить нельзя. Короче, модификацию протокола не предлагать =)

К сожалению, это не вариант :(

Добавлено 16.09.09, 16:53
Тогда такой вопрос... При работе с RAW сокетами предусмотрен какой-нибудь автоматический фильтр по портам хотя бы? Или мы будем обязательно принимать все пакеты, которые поступили на комп, и разбирать всё придётся вручную?

[Хрен]

Вызвано это тем, что идут шифрованные данные.
Во-первых, понижается безопасность, т.к. можем этим выдать смысл зашифрованных данных.
Во-вторых, нет 100% гарантии, что в криптотексте не получится набора символов, аналогичных метке.

Всё это не потому что мне так хочется =)

[Хрен]

Цитата

Что тебе мешает сначала добавить метки, затем поток зашифровать?

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

Добавлено 16.09.09, 19:11

Цитата albom @ 16.09.09, 18:51

Экранирование escape последовательностой полвека назад придумали .

Наверно чего-то недопонял. Пример, допустим, 2-х шифртекстов, разделённых этой самой "экранированной" последовательностью, могёшь показать?

[Хрен]

Походу, мы друг-друга не особо понимаем =)
Приведи пример, как ты себе эту систему видишь. Может я до чего-то элементарного допереть не могу - бывает

[Хрен]

Нет. Есть совершенно отдельные пакеты данных.
<пакет>
<пакет>
.......
<пакет>

Каждый из них заканчивается меткой перевода каретки \r\n.
Каждый пакет ОТДЕЛЬНО шифруется на ГОСТе.
<зашифрованный пакет>
<зашифрованный пакет>
.......
<зашифрованный пакет>

Эти пакеты генерируются, шифруются и передаются ОТДЕЛЬНО, в разные промежутки времени. А на сервере иногда принимаются в следующем виде:
1-й RECV:
<зашифрованный пакет><зашифрованный пакет><зашифрован
2-й RECV:
ный пакет><зашифрованный пакет>

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

Вот.

[Хрен]

Да, это хорошо. Но проблема в том, что в функции шифрования используется ГОСТ с обратной связью (только что узнал). Так что отдельно блоки расшифровать не получится =(

[Alexandoros]

Гост в студию плиз.

[Хрен]

ГОСТ писали не мы, и исходников у нас нет. Так что тут беда с этим =)

[Alexandoros]

ГОСТ это стандарт или название протокола?
Описалово/дока имелось в виду.

[Хрен]

ГОСТ28147-89 - блочный симметричный алгоритм шифрования. Как и большинство БСШ, имеет 3 режима шифрования:
1. простой замены - текст берётся поблочно (блок - 8 байт) и каждый блок шифруется непосредственно на ключе;

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

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


У нас используется 3-й режим. Поэтому читать по 8 байт и расшифровывать отдельно каждый блок не получится =(

[Alexandoros]

Может я туплю в чем то, но как раз здесь все получится по 8 байт расшифровывать. Объясни проблему.

Алгоритм - получаем первый блок(8байт), расшифровуем, результат используем для разшифровки второго блока, результат второго для третьего и т.д. В чем проблема, я не пойму?

[Хрен]

Да, ступил чуть-чуть. Но, к сожалению, та функция по частям расшифровывать не умеет, т.к. после расшифровки проверяет текст на целостность при помощи сравнения имитовставок. Так что ничего не получилось бы.
Но это ужо не важно - решили всё-таки ставить заголовки с длиной пакета =)
Всем спасибо.

[Alexandoros]

Цитата

Но, к сожалению, та функция по частям расшифровывать не умеет,

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