Сообщение Re[2]: Максимальная длина TCP пакета в сети от 10.02.2020 15:16
Изменено 10.02.2020 15:41 AlexGin
Re[2]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Stanislav V. Zudin!
Для начала — вот что я хочу сделать:
http://rsdn.org/forum/network/7502716
Но там теперь НЕ Web-клиент, а толстый клиент.
НЕ протокол HTTP идёт от сервера, а TCP (от применения UDP — я уже давно отказался).
При этом — поддерживается постоянное соединение: сервер-клиент (назовём это — клиентская сессия).
При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes).
Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte.
Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу).
Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
SVZ>MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
SVZ>MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками
Это для меня НЕ страшно — клиент всё равно собирает пакет из нескольких (небольших) фрагментов.
SVZ>Если в сети возникнут какие-то перебои и пакеты потеряются, то будут посланы повторно.
SVZ>Если маршрутизация может поменяться, часть пакетов пойдет другим путём, то есть вероятность смены порядка.
SVZ>Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток.
+100500
Да, работаю с TCP на прикладном уровне, через QTcpSocket (Qt Network)!
Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило).
В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
SVZ>На то он и фуфельный девайс.
Ладно. Для межпроцессной коммуникации в одном компе — совсем даже неплохо.
SVZ>Ты пытаешься сделать собственный WireShark или что?
Что я делаю — я уже указал выше.
Ну а маркер конца пакета я ввёл для того, чтобы собрать на приёме (на клиенте) полный пакет от сервера.
Это вызвано тем, что сеть дробит пакет с результатами вычислений от сервера на небольшие фрагменты.
При этом — маркер конца пакета Я ФОРМИРУЮ И ДОБАВЛЯЮ сам к прикладному пакету (это не то, что использовано под_капотом_протокола_TCP).
Реализация проверки пакета на маркер конца — показалась мне более логичной, чем что-либо другое.
Спасибо за ответ, уважаемый Stanislav V. Zudin!
Для начала — вот что я хочу сделать:
http://rsdn.org/forum/network/7502716
Автор: AlexGin
Дата: 26.07.19
Дата: 26.07.19
Но там теперь НЕ Web-клиент, а толстый клиент.
НЕ протокол HTTP идёт от сервера, а TCP (от применения UDP — я уже давно отказался).
При этом — поддерживается постоянное соединение: сервер-клиент (назовём это — клиентская сессия).
При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes).
Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte.
Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу).
Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
SVZ>MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
SVZ>MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками
Это для меня НЕ страшно — клиент всё равно собирает пакет из нескольких (небольших) фрагментов.
SVZ>Если в сети возникнут какие-то перебои и пакеты потеряются, то будут посланы повторно.
SVZ>Если маршрутизация может поменяться, часть пакетов пойдет другим путём, то есть вероятность смены порядка.
SVZ>Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток.
+100500
Да, работаю с TCP на прикладном уровне, через QTcpSocket (Qt Network)!
Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило).
В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
SVZ>На то он и фуфельный девайс.
Ладно. Для межпроцессной коммуникации в одном компе — совсем даже неплохо.
SVZ>Ты пытаешься сделать собственный WireShark или что?
Что я делаю — я уже указал выше.
Ну а маркер конца пакета я ввёл для того, чтобы собрать на приёме (на клиенте) полный пакет от сервера.
Это вызвано тем, что сеть дробит пакет с результатами вычислений от сервера на небольшие фрагменты.
При этом — маркер конца пакета Я ФОРМИРУЮ И ДОБАВЛЯЮ сам к прикладному пакету (это не то, что использовано под_капотом_протокола_TCP).
Реализация проверки пакета на маркер конца — показалась мне более логичной, чем что-либо другое.
Спасибо за ответ, уважаемый Stanislav V. Zudin!
Re[2]: Максимальная длина TCP пакета в сети
Здравствуйте, уважаемый Stanislav V. Zudin!
Для начала — вот что я хочу сделать:
http://rsdn.org/forum/network/7502716
Но там теперь НЕ Web-клиент, а толстый клиент.
НЕ протокол HTTP идёт от сервера, а TCP (от применения UDP — я уже давно отказался).
При этом — поддерживается постоянное соединение: сервер-клиент (назовём это — клиентская сессия).
При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes).
Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte.
Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу).
Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
SVZ>MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
SVZ>MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками
Это для меня НЕ страшно — клиент всё равно собирает пакет из нескольких (небольших) фрагментов.
SVZ>Если в сети возникнут какие-то перебои и пакеты потеряются, то будут посланы повторно.
SVZ>Если маршрутизация может поменяться, часть пакетов пойдет другим путём, то есть вероятность смены порядка.
SVZ>Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток.
+100500
Да, работаю с TCP на прикладном уровне, через QTcpSocket (Qt Network)!
Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило).
В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
SVZ>На то он и фуфельный девайс.
Ладно. Для межпроцессной коммуникации в одном компе — совсем даже неплохо.
SVZ>Ты пытаешься сделать собственный WireShark или что?
Что я делаю — я уже указал выше.
Ну а маркер конца пакета я ввёл для того, чтобы собрать на приёме (на клиенте) полный пакет от сервера.
Это вызвано тем, что сеть дробит пакет с результатами вычислений от сервера на небольшие фрагменты.
При этом — маркер конца пакета я формирую и добавляю сам к прикладному пакету — при формировании паета на сервере (это не то, что использовано под_капотом_протокола_TCP).
Реализация проверки пакета на маркер конца — показалась мне более логичной, чем что-либо другое.
Спасибо за ответ, уважаемый Stanislav V. Zudin!
Для начала — вот что я хочу сделать:
http://rsdn.org/forum/network/7502716
Автор: AlexGin
Дата: 26.07.19
Дата: 26.07.19
Но там теперь НЕ Web-клиент, а толстый клиент.
НЕ протокол HTTP идёт от сервера, а TCP (от применения UDP — я уже давно отказался).
При этом — поддерживается постоянное соединение: сервер-клиент (назовём это — клиентская сессия).
При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes).
Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte.
Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу).
Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
SVZ>MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
SVZ>MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками
Это для меня НЕ страшно — клиент всё равно собирает пакет из нескольких (небольших) фрагментов.
SVZ>Если в сети возникнут какие-то перебои и пакеты потеряются, то будут посланы повторно.
SVZ>Если маршрутизация может поменяться, часть пакетов пойдет другим путём, то есть вероятность смены порядка.
SVZ>Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток.
+100500
Да, работаю с TCP на прикладном уровне, через QTcpSocket (Qt Network)!
Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило).
В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
SVZ>На то он и фуфельный девайс.
Ладно. Для межпроцессной коммуникации в одном компе — совсем даже неплохо.
SVZ>Ты пытаешься сделать собственный WireShark или что?
Что я делаю — я уже указал выше.
Ну а маркер конца пакета я ввёл для того, чтобы собрать на приёме (на клиенте) полный пакет от сервера.
Это вызвано тем, что сеть дробит пакет с результатами вычислений от сервера на небольшие фрагменты.
При этом — маркер конца пакета я формирую и добавляю сам к прикладному пакету — при формировании паета на сервере (это не то, что использовано под_капотом_протокола_TCP).
Реализация проверки пакета на маркер конца — показалась мне более логичной, чем что-либо другое.
Спасибо за ответ, уважаемый Stanislav V. Zudin!