Сообщение Re[8]: Максимальная длина TCP пакета в сети от 22.02.2020 8:11
Изменено 23.02.2020 8:02 netch80
Re[8]: Максимальная длина TCP пакета в сети
Здравствуйте, 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. Там влезть невовремя невозможно. Не уводи тему вбок.
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. Там влезть невовремя невозможно. Не уводи тему вбок.
Re[8]: Максимальная длина TCP пакета в сети
Здравствуйте, 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. Там влезть невовремя невозможно. Не уводи тему вбок.
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. Там влезть невовремя невозможно. Не уводи тему вбок.