да, если по сети гонять base64, тогда можно искать признак конца по всяким "\r\n\r\n" =)
но не хочется все конвертить в base64 и обратно...
да и оверхед добавляется еще и тот, что в потоке данных нужно искать эти самые "\r\n\r\n" %)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, GarryIV, Вы писали:
GIV>В http размер тела тоже передается либо сразу либо чанками. И отключатся совсем необязательно.
кстати да. так это один из вариантов? или оно всегда?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: текстовый протокол без передачи размера пакета
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, GarryIV, Вы писали:
GIV>>В http размер тела тоже передается либо сразу либо чанками. И отключатся совсем необязательно. X>кстати да. так это один из вариантов? или оно всегда?
Два варианта либо размер в заголовке content-lenght либо без заголовка но передавать кусками-чанками,там в начале чанка размер потом тело чанка и это дело повторяется.
Здравствуйте, niXman, Вы писали:
X>как вообще подобное делается(кроме HTTP)?
Вообще префиксирование длиной имеет свои плюсы и минусы, думаю это очевидно.
HTTP позволяет и щас не передавать длину, а ориентироваться на закрытие соединение... но, в среде, с не надежной передачей данных (TCP, шлюзы, прокси), клиенту сложно ответить на вопрос — получен ли ответ полностью... а потом получается — файл скачан, но не до конца и ошибок нет (что-то такое в памяти всплывает, как страшный сон, хотя мож софт кривой был). Поэтому любые вариации на тему Content-Length / chunked всегда выигрывают, в этом отношении.
Впрочем, даже, если это просто файл на диске — длина может помочь увидеть, что с файлом что-то не то.
В текстовых протоколах не фиксированной ширины/размера чаще всего пользуются или разделителями, или все той же префиксной длиной, просто записанной в тексте.
Например:
6\nданные
Некоторые вплавливают данные прям в бинарном виде.
Вообще, имхо, если размер данных заранее известен — то простое префиксирование. Если поток или размер пакетов довольно большой — то чанки.
К разделителям отношусь скептически, с той точки зрения, что если мы передает блоб в 1мб — то зачем его сканировать?
Re: текстовый протокол без передачи размера пакета
Здравствуйте, Zhendos, Вы писали:
Z>Например есть https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing Z>благодаря тому, что только одно значение использовать как разделитель пакетов, Z>то при кодировании длина получается меньше чем в base64
нужно вникнуть. но уже это кажется заменой одного шила на другое мыло...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
X>спасибо.
У шифра есть размер блока.
Принимаешь, расшифровываешь по-блочно, собираешь, и смотришь не имеется ли признака конца в расшифрованном блоке.
Скрытый текст
"Это конец" — подумал Штирлиц, сидя за дерминалом древнего Мака, — "А где же linefeed?"
Как много веселых ребят, и все делают велосипед...
Re[2]: текстовый протокол без передачи размера пакета
Здравствуйте, ononim, Вы писали:
O>У шифра есть размер блока.
у какого? AES?
но я использую xchacha20, и не вижу в доке ничего про размер блока, только упоминание о том, что максимальный размер блока 256 гигов 2^64 bytes.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
O>>У шифра есть размер блока. X>у какого? AES? X>но я использую xchacha20, и не вижу в доке ничего про размер блока, только упоминание о том, что максимальный размер блока 256 гигов 2^64 bytes.
Internally, XChaCha20 works like a block cipher used in counter mode
O>Internally, XChaCha20 works like a block cipher used in counter mode
по ссылке перехожу и табличку вижу, но процитированного текста на странице нет.
O>https://libsodium.gitbook.io/doc/secret-key_cryptography/aead#availability-and-interoperability O>Block size --> 512 bits O>Если шифруешь меньше то оно либо зафэйлится либо сделает padding нулями (а при расшифровке соответственно его поскипает).
если это "внутренности", стОит ли на них расчитывать? внутренности могут же измениться...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[5]: текстовый протокол без передачи размера пакета
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, GarryIV, Вы писали:
GIV>>В http размер тела тоже передается либо сразу либо чанками. И отключатся совсем необязательно. X>кстати да. так это один из вариантов? или оно всегда?
По дефолту, в версии 1.0 HTTP-коннект предполагает закрытие соединения сервером после выдачи ответа, а в версии 1.1 наоборот — коннект считается Keep-Alive, если явно не указано другое.
Re[5]: текстовый протокол без передачи размера пакета
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, ononim, Вы писали:
O>>https://libsodium.gitbook.io/doc/secret-key_cryptography/aead#availability-and-interoperability O>>Block size --> 512 bits O>>Если шифруешь меньше то оно либо зафэйлится либо сделает padding нулями (а при расшифровке соответственно его поскипает). X>если это "внутренности", стОит ли на них расчитывать? внутренности могут же измениться...
У других шифров может быть иной принцип паддинга, например, PKCS — а там байт-заполнитель может зависеть от длины заполняемого "хвоста". Да и паддинга может просто не быть.
Re: текстовый протокол без передачи размера пакета
Здравствуйте, niXman, Вы писали:
X>привет!
X>ну вот, к примеру, в бинарных протоколах: передается размер пакета за которым следует само тело. X>тут все понятно.
X>ну, или, как в HTTP: записываешь тело и отключаешься. X>тоже понятно. но очень медленно.
X>хочу сделать следующее: X>передавать JSON в зашифрованном виде. но после шифрования данные уже не текстовые(если не преобразовывать в base64).
X>как вообще подобное делается(кроме HTTP)?
X>спасибо.
Ну, вообще если данные текстовые, то ты можешь использовать некий спец символ для того чтобы сигнализировать о конце предыдущего сообщения и о начале следующего. Но после шифрования данные у тебя уже бинарные, соответственно могут содержать любую последовательность символов, так что придется их как-то перекодировать (не обязательно в base64). Но, если данные у тебя все-таки уже бинарные, что мешает тебе использовать бинарный протокол и добавлять в начало каждого сообщения заголовок с размером этого сообщения.