Здравствуйте, netch80, Вы писали:

Pzz>>>Контрольная сумма в езернете
M>>Она же только на заголовок?

N>На весь кадр.

Да, перепутал

Здравствуйте, AlexGin, Вы писали:

AG>...
AG>Блок в 10 байт — войдёт всегда и фактически без доп-проверок.
AG>Чего совсем не сказать о блоке в 10 килобайт.

AG>P.S. Проблему удалось решить — за счет контроля длины блоков.
AG>Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.

Маркер конца — вообще какая-то малоосмысленная штука. А вот маркер начала, длину, или CRC я бы оставил — если что, будет легко перейти на другие протоколы/физический уровень — хоть тот же UART

Здравствуйте, AlexGin, Вы писали:

AG>IMHO — это зависит от уровня ответственности ПО:
AG>- многопользовательская сетевая игра — да в здравом уме никто не защищается от описанной ситуации!

Зато защищаются от читеров, на лету меняющих пакеты, и зачастую шифруют канал. Ты выбрал плохой пример.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, AlexGin, Вы писали:

AG>>IMHO — это зависит от уровня ответственности ПО:
AG>>- многопользовательская сетевая игра — да в здравом уме никто не защищается от описанной ситуации!

Ops>Зато защищаются от читеров, на лету меняющих пакеты, и зачастую шифруют канал. Ты выбрал плохой пример.

Возможно и плохой, сути это не меняет.
Мы прекрасно понимаем, что здесь криптозащита — это не столько технически необходимый элемент, сколько социально...

Здравствуйте, AlexGin, Вы писали:

AG>Я при разработке протокола обмена сделал так, чтобы новый блок данных отправлялся только после того,
AG>как противоположная сторона приняла предшествующий блок (и передала нам квитирующий блок).
AG>То есть — приведенный выше сценарий не реален. Даже для стримов.

Просядет перфоманс по сети из-за таких round-trip.

Здравствуйте, AlexGin, Вы писали:

AG>Были случаи, что около 30 килобайт (на JSON-варианте), теперь — с сериализацией через QDataStream — удалось выйти на размер менее 10 килобайт.
Вы изобретаете протокол IP, реализуя его внутри протокола TCP.
Не надо так делать. Кесарю — кесарево.

Здравствуйте, Pzz, Вы писали:

Pzz>Что-то одно из двух убрать, или длину, или маркер конца. С длиной приемник будет эффективнее работать: не надо будет сканировать каждый байт в поисках маркера.

Вообще говоря, что эффективнее — сильно зависит от задачи. Если источник данных заранее знает размер блока, то да, для всех лучше вначале писать размер. В противном случае — необходимость писать размер блока приведет к просадке производительности источника. В качестве примера протокола с маркером конца можно привести http заголовок Transfer-Encoding: chunked . К тому же в этом протоколе нет необходимости сканировать каждый байт на приемнике, win-win решение

Здравствуйте, Mr.Delphist, Вы писали:

AG>Я при разработке протокола обмена сделал так, чтобы новый блок данных отправлялся только после того,
AG>как противоположная сторона приняла предшествующий блок (и передала нам квитирующий блок).
AG>То есть — приведенный выше сценарий не реален. Даже для стримов.

MD>Просядет перфоманс по сети из-за таких round-trip.

Кого интересует "перфоманс_по_сети" ?
Если Заказчика устраивает общая скорость работы приложения, то зачем ещё что-то придумывать?

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:

AG>Были случаи, что около 30 килобайт (на JSON-варианте), теперь — с сериализацией через QDataStream — удалось выйти на размер менее 10 килобайт.

S>Вы изобретаете протокол IP, реализуя его внутри протокола TCP.

При чём здесь JSON/"двоичние_данные" к IP или TCP?


S>Не надо так делать. Кесарю — кесарево.

Здравствуйте, AlexGin, Вы писали:
AG>
Не то порезал.
Вот эта ваша цитата:

| Marker_1 | | to Server: On the Client exist packet (message) to the Server
| Marker_2 | to Client: Server is Ready to recive packet (message) from the Client
{User's-Packet} | | to Server: transmitting of User's-Packet from Client to the Server
| Marker_3 | to Client: Success — packet (messege) correctly received and processed

Это попытка изобрести протокол TCP.

Здравствуйте, уважаемый Sinclair, Вы писали:

S>Это попытка изобрести протокол TCP.

Хорошо, какие есть предложения...

Гонять видео по сети — там, где оно нафик не надо?
Передавать фоновый поток ничего не значащих данных — только чтобы заполнить канал?
Что-то ещё, не требуемое для диалога между программными компонентами системы?

Всё-таки во главу угла следует ставить контекст задачи, а не ту или иную реализацию.
Тем более, что приведенный мной протокол — вполне работоспособен на TCP. А все остальные моменты — можно отбросить.

P.S. Файловый ввод-вывод также поддерживеет потоки.
Так почему нам, вместо докумениа на 20 килобайт, не залепить 4-ГБ видео?

Здравствуйте, AlexGin, Вы писали:
AG>Всё-таки во главу угла следует ставить контекст задачи, а не ту или иную реализацию.
AG>Тем более, что приведенный мной протокол — вполне работоспособен на TCP. А все остальные моменты — можно отбросить.
Смотрите, есть протокол IP. Просто отправляем датаграммы. Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.
Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.
Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".

AG>P.S. Файловый ввод-вывод также поддерживеет потоки.
AG>Так почему нам, вместо докумениа на 20 килобайт, не залепить 4-ГБ видео?
Я ваш вопрос не вполне понимаю.

Здравствуйте, уважаемый Sinclair, Вы писали:

S>Смотрите, есть протокол IP. Просто отправляем датаграммы.
Да, я в курсе. Есть. Это как-бы этажём ниже (по 7-ми уровневой модели OSI).

S>Есть протокол ICMP, при помощи которого участники IP — сети сигнализируют друг другу всякие служебные вещи.

Да — ping a.b.c.d — это всё Internet Control Message Protocol.

S>Есть протокол TCP, который построен поверх IP таким образом, чтобы из датаграмм сделать поток. Вот эти все "можно, я к вам подключусь" — "да, подключайтесь пожалуйста" — "извините, я так и не получил пакет 65552224, а вы уже давно шлёте мне пакеты с большими номерами" — "простите, рестартую передачу с пакета 65552224" в нём уже изобретено.

Да, я в курсе (уже не первый год). Это называют ориентированный_на_соединение_протокол.
Что совсем не отменяет принцип "доверяй, но проверяй". Так, то же контрольное суммирование имеется на разных уровня.
Не нужно надеяться что умный дядька всё за меня сделал.
Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
я понадеялся на приём полного блока данных. Ну вполне логично же...
Но — тут такой вот нежданчик...
Теперь — в начале блока пишу длину и делаю накопление.
После этого стало нормально.

S>Не надо пытаться вложить TCP в TCP. Надо просто аккуратно читать данные из потока, не ориентируясь на размеры приходящих "порций".

Да, какие-то элементы протокола будут дублироваться на прикладном уровне.
Тем более, что следует учитывать разных вариантов реализаций взаимодействия и способов (асинхронный/синхронный).
Так, например, можно иметь асинхронный способ (сообщения), а можно и старый-добрый синхронный (типа send/recv) вынести в отдельный поток выполнения.

AG>>Файловый ввод-вывод также поддерживает потоки.
AG>>Так почему нам, вместо документа на 20 килобайт, не залепить 4-ГБ видео?
S>Я ваш вопрос не вполне понимаю.

Ну так файловые операции ведь также:
1) Не используют всё время всю производительность файловой системы;
2) Действия верхнего и нижнего уровня — зачастую в чём-то дублируют друг друга.

P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя —
и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).

Здравствуйте, AlexGin, Вы писали:

AG>Так, например, этот пост появился оттого, что начитавшись теории об ориентированности_на_соединение,
AG>я понадеялся на приём полного блока данных. Ну вполне логично же...
Вот тут противоречие. Если бы речь шла об ориентированности на пересылку пакетов, то можно было бы надеяться на приём и получение блоков.
Скажем, получить половинку UDP датаграммы вы не сможете.
А стрим как раз и характерен тем, что режется на пакеты произвольным образом.

AG>Теперь — в начале блока пишу длину и делаю накопление.
AG>После этого стало нормально.
Ну вот есть подозрение, что и другие фичи вы изобретаете повторно

AG>P.S. Пусть Вас не удивляет наличие "предбанника" в моём протоколе — когда источник информации говорит: у меня данные для тебя -
AG>и приёмник должен подтвардить: это сделано для дополнительной синхронизации по загрузке процессров:
AG>так, если приёмная сторона занята обработкой некой порции информации, то пока имеется загрузка CPU — маркер разрешения
AG>передачи основного блока данных (третий шаг/третья строк по моей таблице) будет задержан (ориентировочно на 1...2 сек).
Ну, может быть и взлетит.

Здравствуйте, Mr.Delphist, Вы писали:

Pzz>>>Я где-то читал, что эти needfrag не всегда доходят и не всегда посылаются, поэтому с ними бывают всякие разные проблемы. Не помню, включен ли MTU path discovery в линухе по умолчанию, а проверять лень...
N>>Включен. Не всегда посылаются — да, бывает, но последние лет 10 я про такое уже не слышал. Может, даже самые тупые и ленивые наконец починились...
MD>Если гейт посередине закрывает/зацикливает ICMP (например, для защиты от флуд-атак или как одно из мероприятий по усложнению сканирования структуры сети), то будет резать весь ICMP даже если стороны посылают друг другу fragmentation-инструкции.

Можно искать оправдания любой глупости, но это таки глупость. ICMP needfrag нужен в ответ на уже допущенный пакет, даже если UDP. А тем более если это TCP — необходимость в нём возникает только для уже установленного соединения, а тогда такой гейт должен знать про соединение. Не хочешь пропускать ответные ICMP — просто не допускай пакеты внутрь, когда не надо.
Ну да, на практике авторов такого дерьма много — поэтому и приходится придумывать обходные меры типа автоуменьшения до мин. MTU...

Здравствуйте, Marty, Вы писали:

AG>>P.S. Проблему удалось решить — за счет контроля длины блоков.
AG>>Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.

M>Маркер конца — вообще какая-то малоосмысленная штука.

Есть много примеров неплохой практики для такого маркера.
SMTP, POP3, NNTP и прочие: маркер конца — строка из одной точки.
HTTP chunked encoding: маркер конца — чанк длины 0.
ATM: AAL5 для транспорта IP — бит пометки "последний фрагмент IP пакета" (если позанудствовать, тоже, вероятно, фрагмента, но уже на уровне IP).
Да даже просто текстовый интерфейс с другой стороной: маркер конца — LF или CRLF, начало предполагается автоматически (пришёл на линк и послал AT\n).
А пока он не пришёл — набираешь данные. Да, заранее тут не предскажут их длину, надо иметь свой лимит и возможность запасти до него.
И это не противоречит возможности продублировать длиной в конце (для сверки) или CRC.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, AlexGin, Вы писали:
AG>>
S>Не то порезал.
S>Вот эта ваша цитата:
S>

S>| Marker_1 | | to Server: On the Client exist packet (message) to the Server
S>| Marker_2 | to Client: Server is Ready to recive packet (message) from the Client
S>{User's-Packet} | | to Server: transmitting of User's-Packet from Client to the Server
S>| Marker_3 | to Client: Success — packet (messege) correctly received and processed

S>Это попытка изобрести протокол TCP.

Это только если сервер принимает всё от клиента в порядке FIFO. А если что-то более сложное? Несколько потоков данных с разными приоритетами, новые сообщения, которые отменяют старые, так что их вообще не надо пересылать... ТС ведь про это ничего не говорил, может, ему вскоре и такое нужно. Тогда уже надо минимум смотреть на SCTP, а может, и таки что-то своё изобретать поверх.

Здравствуйте, netch80, Вы писали:

AG>>>P.S. Проблему удалось решить — за счет контроля длины блоков.
AG>>>Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.

M>>Маркер конца — вообще какая-то малоосмысленная штука.

N>Есть много примеров неплохой практики для такого маркера.
N>SMTP, POP3, NNTP и прочие: маркер конца — строка из одной точки.

Плохие примеры. Эти протоколы разрабатывались в те времена, когда по ним общались не программы, а люди

N>HTTP chunked encoding: маркер конца — чанк длины 0.

Лень уточнять, о чем тут, но весь HTTP изначально текстовый человеко-читаемый, так что грабли растут примерно оттуда же

N>ATM: AAL5 для транспорта IP — бит пометки "последний фрагмент IP пакета" (если позанудствовать, тоже, вероятно, фрагмента, но уже на уровне IP).
N>Да даже просто текстовый интерфейс с другой стороной: маркер конца — LF или CRLF, начало предполагается автоматически (пришёл на линк и послал AT\n).
N>А пока он не пришёл — набираешь данные. Да, заранее тут не предскажут их длину, надо иметь свой лимит и возможность запасти до него.
N>И это не противоречит возможности продублировать длиной в конце (для сверки) или CRC.

Маркер конца может быть полезен в купе с остальным, не более.

Вот тебе по UART'у шлют: "убить нельзя помиловать\r\n", а ты не вовремя влез и получил "нельзя помиловать\r\n". Маркер конца есть? Есть. Пошли убивать, сообщение вполне однозначное

Здравствуйте, Marty, Вы писали:

AG>>>>P.S. Проблему удалось решить — за счет контроля длины блоков.
AG>>>>Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.
M>>>Маркер конца — вообще какая-то малоосмысленная штука.
N>>Есть много примеров неплохой практики для такого маркера.
N>>SMTP, POP3, NNTP и прочие: маркер конца — строка из одной точки.
M>Плохие примеры. Эти протоколы разрабатывались в те времена, когда по ним общались не программы, а люди

Это с какого потолка ты взял? По ним всегда в первую очередь общались программы, и гарантия протокола была сделана под корректность их общения. Да, было сделано удобство для контроля и отладки человеком — там, где это не портит производительность (т.е. почти везде), но однозначность формирования и разбора именно машинная.

N>>HTTP chunked encoding: маркер конца — чанк длины 0.
M>Лень уточнять, о чем тут, но весь HTTP изначально текстовый человеко-читаемый, так что грабли растут примерно оттуда же

"Человеко-читаемый" и "предназначенный для человека" это принципиально разные вещи.
И на бинарном HTTP/2 chunked-передача точно такая же, последовательность чанков, завершаемая признаком конца.

M>Вот тебе по UART'у шлют: "убить нельзя помиловать\r\n", а ты не вовремя влез и получил "нельзя помиловать\r\n". Маркер конца есть? Есть. Пошли убивать, сообщение вполне однозначное

У нас контекст — TCP, а не UART. Там влезть невовремя невозможно. Не уводи тему вбок.