Здравствуйте, уважаемый netch80, Вы писали:
AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта
N>Имеется в виду вариант типа такого: N>вызвали recv() — пришло, например, 1460 байт (типовой MSS на Ethernet без timestamp-опций). N>Из них 1458 — первое сообщение с заголовком длины. А ещё 2 — начало заголовка длины второго сообщения. N>Теперь надо эти 2 сохранить, ответ следующего recv() дописать к ним и уже тогда декодировать длину.
Как я уже упоминал: следующий блок (пакет_пользовательского_уровня) — у нас ждёт.
Ждёт, пока не отработает предшествующий блок. Так я задумал и реализовал протокол верхнего (прикладного) уровня.
Посему, указанная Вами, уважаемый netch80, ситуация (с двумя байтами от нового блока) невозможна в принцыпе.
Да, я в курсе — что не использовал все возможности TCP. А именно — потоковые возможности.
Но от системы не требуется гонять (порно)фильмы, чтобы хоть как-то избежать простоя канала
Здравствуйте, AlexGin, Вы писали:
SVZ>>На твоём прикладном уровне все пакеты на месте и в нужном порядке. AG>+100500 AG>Я в курсе, что теория говорит об этом. Практика иногда может и отличаться
Не отличается.
SVZ>>Там всё немного сложнее. Подтверждаться может не каждый пакет, а целая цепочка. AG>На моей (прикладной) стороне — обеспечена передача квитирования в сторону сервера, когда на клиенте приняли пакет (ну или же собрали из фрагментов)
Естественно, так как нет никакой гарантии, что пакеты доходят вообще. Посылка сообщения сервером не означает его доставку. TCP тут не причём.
Здравствуйте, Pzz, Вы писали:
Pzz>Что до вебсокета, он превращает HTTP в, практически, TCP-сокет с навешенным на него фреймингом. В терминах HTTP это называется protocol upgrade
Здравствуйте, Reset, Вы писали:
Pzz>>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
R>У тебя вместе с tcp 3-4 уровня (физический, Ethernet(может не быть), IP, TCP) и на каждом своя контрольная сумма. Это как должен шуметь канал, чтобы данные по нему все же бегали, но иногда на всех 4-х уровнях контрольные суммы все же совпадали.
У IP контрольная сумма только на свой заголовок. Но в главном ты прав
Здравствуйте, AlexGin, Вы писали:
AG>Я же проверяю не все байты, а только четыре_последних_байта на маркер конца:
Странная технология. Во всех известных мне протоколах используют маркер начала без или с размером сообщения, и (не всегда) с контрольной суммой в конце. Размер сообщения, вместе с контрольной суммой, обеспечивает приемлемую для боьшинства случаев надежность.
ЗЫ А перед маркером конца размер сообщения не задаешь? Ну, просто чтобы было проще найти его начало
Здравствуйте, Pzz, Вы писали:
Pzz>Не надо при проектировании framing'а полагаться на то, что фреймы эти будут использоваться строго в режиме вопрос-ответ. Ничего особо не выигрываешь, а лишь смешиваешь два логически не связанных уровня. О чем потом и пожалеешь.
Почему не надо? А если захочется запустить протокол поверх RS485?
Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Здравствуйте, уважаемый Marty, Вы писали:
M>Здравствуйте, AlexGin, Вы писали:
M>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты
Я — аналогично.
Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно.
Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
Совсем другое — массив длиной от 10 байт до 10 килобайт.
Причём, если раньше в моих же проектах блок данных (пакет прикладного уровня) на TCP исчерпывался 256 байт фикс-длины,
то также никаких траблов замечено не было.
M>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй
Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Ну, она CRC32. В массштабах 4-гигабайтного кино вероятность пропустить одиночную ошибку больше половины. С другой стороны, кто его качает, кино, по голому TCP?
А я то думал, что для передачи "4-гигабайтного кино" более подходит UDP протокол.
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Здравствуйте, AlexGin, Вы писали:
Pzz>Не надо при проектировании framing'а полагаться на то, что фреймы эти будут использоваться строго в режиме вопрос-ответ. Ничего особо не выигрываешь, а лишь смешиваешь два логически не связанных уровня. О чем потом и пожалеешь.
Ну OK — чтобы заполнить канал передачи, помимо диалога Server-Client будем передавать фильмы.
Или торрент-сеть организуем
Вот не знаю — что выбрать?
Pzz>Я даже не о пропускной способности канала сейчас говорю, а о логической целостности твоего протокола.
Мой протокол — это "разговор" двух человек аппаратно-программных сущностей: сервер и клиент...
Что предлагается как альтернатива диалогу — передача "пустого" space-holder-а, пока требуемого контента не насобиралось?
Здравствуйте, AlexGin, Вы писали:
Pzz>>Ну, она CRC32. В массштабах 4-гигабайтного кино вероятность пропустить одиночную ошибку больше половины. С другой стороны, кто его качает, кино, по голому TCP? AG> AG>А я то думал, что для передачи "4-гигабайтного кино" более подходит UDP протокол.
По разному бывает. Иногда для этого лучше всего подходит битторрент.
Здравствуйте, AlexGin, Вы писали:
AG>Мой протокол — это "разговор" двух человек аппаратно-программных сущностей: сервер и клиент... AG>Что предлагается как альтернатива диалогу — передача "пустого" space-holder-а, пока требуемого контента не насобиралось?
Предлагается не рассчитывать в парсере фреймов на то, что передатчик передаст целый фрейм и остановится.
Здравствуйте, AlexGin, Вы писали:
AG>При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes). AG>Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte. AG>Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу). AG>Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
Сейчас такие вещи делают на базе очередей.
Твой клиент закидывает свое задание (JSON) в очередь задач, и подписывается на очередь ответов.
Твой сервер (или несколько серверов) вытаскивают задачи из очереди задач, выполняют их, и помещают результат в очередь ответов.
Для хранения и поддержки очередей используется специальные серверы — брокеры сообщений.
Они работают по протоколам AMQP или MQTT (поверх TCP/IP).
Зачем создавать новый протокол? Все уже реализовано.
Здравствуйте, AlexGin, Вы писали:
M>>Всю жизнь работаю с потоковыми средами передачи данных — TCP, UART, RS485, CAN, TCP (да хоть те же файлы или пайпы) — всегда строится КА (обычно не слишком сложный) разбора потока байт, который выплевывает на вышестоящий уровень готовые пакеты AG> AG>Я — аналогично. AG>Но сравнивать UART (или RS485) с TCP — не буду. Это нелогично и неверно. AG>Одно дело — передать 10 байт, причём их всегда десять (ну даже если в 2-3 раза больше — обычно длина константна).
У кого-то константна, у кого-то нет, но речь не об этом
AG>Совсем другое — массив длиной от 10 байт до 10 килобайт.
И какая тут принципиальная разница?
AG>Причём, если раньше в моих же проектах блок данных (пакет прикладного уровня) на TCP исчерпывался 256 байт фикс-длины, AG>то также никаких траблов замечено не было.
M>>Зачем что-то изобретать, когда кучи DLE ETX протоколов существуют, с размерами пакетов, контрольными суммами на любой вкус, и прочим блек-джеком. Бери любой, делай свою контрольную сумму — CRC, MD5, SHA256 и тп и используй AG> AG>Да вроде как здесь выше сообщалось, что КС в подсистеме TCP проверяется "под_капотом"...
