Здравствуйте, AlexGin, Вы писали:
AG>Вопросы: AG>MTU равный примерно 1.5 KBytes — это для произвольных данных? AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Я не вижу там цифру типа 14KB. Вижу 1400. Вы один ноль не додумали?
По сути:
1. Как уже сказано, TCP поддерживает просто октетный поток. Что отправлено с одной стороны, придёт (если вообще придёт) на другую, в том же порядке и том же составе, без добавлений, потерь и модификаций. Ну, точнее, бывают разные случаи: бывает, что у маршрутизаторов память битая, или какое ещё безобразие. Какими порциями будет читаться на приёме — неизвестно, поэтому надеяться на передачу теми же порциями нельзя, нужно иметь метки в самом потоке.
2. MTU определяется как детектированный минимум из всех линков по дороге пакета до ремотного хоста. Именно что всех, а не только ближайших. Реально в нынешнем мире не бывает интерфейса, кроме loopback и спец. локальных настроек, у которых MTU самого линка более 1500. Меньше — бывает — если проследует через интерфейс. И ещё вычтите 52 байта на IP+TCP (иногда 40, но это всё реже и реже).
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Пакетов — может. Но волновать не должно, если не стоит задача выжать дополнительные проценты скорости (а в таком случае TCP вообще не в тему).
AG>Вышеуказанные данные получены экспериментально. AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
Это loopback, ему можно. Бывает ethernet jumbo frames, до 9000 — но только в локальных сетях.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP? AG>Как защититься от изменения порядка следования пакетов?
Здравствуйте, reversecode, Вы писали:
R>может на практике когда сильно умные DPI или оборудование у прова которое не выдерживает транзита R>если не сильно большой pps и не сильно заумный траффик R>тогда можно не волноваться
Здравствуйте, 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. Там влезть невовремя невозможно. Не уводи тему вбок.
Я бы на твоем месте, передавал блоки данных с длинной в заголовке блока (чтобы не парсить в поисках маркера конца, кроме того, с маркером ты не сможешь передавать в данных последовательность, используемую для маркера). Про MTU и все что лежит ниже уровня TCP тебе лучше сейчас вообще забыть, т.к. оно не влияет на передачу данных твоего приложения. То, что ты когда-то не смог найти маркер конца пакета и решил, что данные были изменены по пути — скорее всего ошибка в твоем приложении. Про то, что TCP потоковый протокол, тебе уже рассказали.
В общем, передавай данные блоками с длинной в заголовке. Читай до тех пор, пока не получишь весь блок целиком (тут нужно будет обрабатывать возможность отключения клиента и, возможно, другие ошибки типа таймаута). И все будет у тебя работать, как надо.
Маркер тебе не нужен, если очень хочется проверить целостность данных — используй контрольную сумму в виде sha256 (опять же в заголовке или в хвосте данных). Еще большую надежность даст TLS, но тогда придется заморочиться с сертификатами и чуть увеличится время подключения (на 1RTT/время туда-сюда). Накладные расходы на шифрование и дополнительные копирования ничтожны, если только ты не делаешь сервер Netflix (а это точно не так).
P.S. Если захочешь разобраться с MTU и как там оно устроено на более низких уровнях — это всегда пожалуйста, спрашивай. Но сейчас для твоего прикладного протокола тебе это не надо.
P.P.S. У TCP есть включенный по умолчанию алгоритм минимизации количества пакетов (гуглить по "TCP_NODELAY"). Когда TCP пакет сформирован не целиком (записали 10 байт, например, а в TCP пакет влезает 1460, или записали 10K и в последнем пакете еще осталось место), то пакет ждет несколько ms, вдруг появятся еще данные, чтобы их тоже отправить в том же пакете (целиком сформированные пакеты пойдут в сеть сразу, им нет смысла ждать). Тебе, возможно, полезно отключить эту задержку, чтобы при записи в сеть блока данных, он тут же начал отправляться без задержки.
Здравствуйте, AlexGin, Вы писали:
N>>В чём эта "практика"? Если вы учитываете, какими порциями смог прочитать recv() на приёмнике — вы уже успешно выстрелили себе в ногу. Не надо так.
AG>Ну хорошо — я накопил данные от первого recv(), затем следующего и т.д — пока не уяснил что блок_пользовательских_данных принят весь. AG>Блок_пользовательских_данных — это тот полный набор данных, что следует от сервера к клиенту. AG>Таким образом, если при передаче по сети его разбило на несколько частей, то я их могу "накопить" и соединить вместе. AG>Так нормально?
Да, так нормально.
Теперь надо решить, как определять, что передача от сервера закончилась (а для сервера — аналогично от клиента). Есть разные стили фрейминга для этого. Например, один из классических — вначале идёт длина всей посылки в двоичном виде (например, 4 байта в network order == big-endian). Но можно придумать тысячи других по вкусу.
Здравствуйте, AlexGin, Вы писали:
AG>... AG>Блок в 10 байт — войдёт всегда и фактически без доп-проверок. AG>Чего совсем не сказать о блоке в 10 килобайт.
AG>P.S. Проблему удалось решить — за счет контроля длины блоков. AG>Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.
Маркер конца — вообще какая-то малоосмысленная штука. А вот маркер начала, длину, или CRC я бы оставил — если что, будет легко перейти на другие протоколы/физический уровень — хоть тот же UART
Здравствуйте, AlexGin, Вы писали:
AG>При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes). AG>Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte. AG>Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу). AG>Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
Сейчас такие вещи делают на базе очередей.
Твой клиент закидывает свое задание (JSON) в очередь задач, и подписывается на очередь ответов.
Твой сервер (или несколько серверов) вытаскивают задачи из очереди задач, выполняют их, и помещают результат в очередь ответов.
Для хранения и поддержки очередей используется специальные серверы — брокеры сообщений.
Они работают по протоколам AMQP или MQTT (поверх TCP/IP).
Зачем создавать новый протокол? Все уже реализовано.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>>Ну, она CRC32. В массштабах 4-гигабайтного кино вероятность пропустить одиночную ошибку больше половины. С другой стороны, кто его качает, кино, по голому TCP? AG> AG>А я то думал, что для передачи "4-гигабайтного кино" более подходит UDP протокол.
В любой физически реальной среде передачи действует принцип, аналогичный известному лозунгу: "Мы делаем быстро, качественно и дёшево — выберите любые два". (Это действует как для сетей с коммутацией пакетов, так и для сетей с коммутацией каналов, хотя мы здесь обсуждаем только TCP/IP — это коммутация пакетов.) Аналогами этих вариантов являются соответственно:
— скорость и оперативность передачи данных
— надёжность передачи данных (защита от потерь, искажений)
— экономность передачи (требовать ресурсы, сравнимые с затратой в идеальных условиях)
Три комбинации двух вариантов из трёх дают три стиля трафика:
1. Наливной (англ. bulk). Надёжность и экономность передачи достигаются за счёт снижения скорости при проблемах передачи: неподтверждённые данные пересылаются до достижения результата или определения невозможности связи. Яркие примеры применения — скачивание фильма, доступ к базе данных для выписки товара. Именно такое обычно делается поверх TCP.
2. Синхронный. Скорость и экономность важнее, допускается определённая потеря данных при передаче (которая для большинства целей применения такого типа трафика лучше, чем задержка
вследствие попыток перепосылки). Яркие примеры применения — voice-over-IP, потоковое видео... Яркий пример реализации — RTP.
Вот тут как раз место для UDP.
3. Управляющий. Важнее достучаться вовремя до получателя и получить подтверждение об этом, чем экономия ресурсов (хотя практически, безусловно, реализации не стараются поглощать всё — и дизайн протокола должен не допускать неконтролируемый рост объёмов и скоростей потоков данных). Примеры реализации — STP, OSPF, сигнальный уровень SIP.
Итого: смотрите фильм вживую — UDP (ну, для отдельных героев — SCTP с ограниченной доставкой). Скачиваете — TCP. Смешивать подходы нежелательно, у них совсем разные задачи.
Здравствуйте, AlexGin, Вы писали:
SVZ>>Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток. AG>Да, работаю с TCP на прикладном уровне, через QTcpSocket (Qt Network)!
AG>Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило). AG>В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
Я подозреваю, ты немного о другой разбивке.
Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано.
Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов. В общем не парься.
Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, AlexGin, Вы писали:
AG>Этот массив — может представлять собой целый блок (ну то-есть пользовательский_пакет) или же только его фрагмент. AG>Я же проверяю не все байты, а только четыре_последних_байта на маркер конца:
А что ты будешь делать, если у тебя эти четыре байта разрезались между двумя фрагментами?
AG>- если его нет, то помещаю этот массив в "накопитель" и жду недостающие фрагменты; AG>- если он есть — считаем что блок данных успешно принят — его можно применять.
И ты сразу подрезал себе возможность посылать запросы не по одному, а сразу пачками, а потом получить пачку ответов.
Здравствуйте, Marty, Вы писали:
M>О какой потере промежуточных пакетов в TCP идет речь?
+100500
Теоретически — да, вроде как этого не должно (и не может) быть.
Практически же — есть провод (грубо говоря) и он вдруг потерял контакт. Ну скажем на пару секунд...
Теоретически — при этом или не совпадут контрольные суммы пакетов_нижнего_уровня или будет time-out.
Практически же — никто не знает. Ну или же каждый разработчик прикладного ПО на_верхнем_уровне защищается от ситуации по-своему.
Здравствуйте, AlexGin, Вы писали:
AG>Вопрос: какова максимальная длина пакета, который НЕ будет разбиваться сетью на более мелкие пакеты? AG>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
MTU — это параметр сетевого интерфейса, который определяет максимальный размер пакета (все равно какого, TCP, UDP, ICMP...), который не будет фрагментироваться при отправке через этот интерфейс.
TCP, естественно, не хочет, чтобы его пакеты фрагментировались. Поэтому при соединении по локальной сети TCP будет ориентироваться на MTU, за вычетом служебных данных. А вот если соединение нелокальное, то у TCP нет знаний о том, как будет происходить фрагментация на промежуточных узках. Поэтому он будет исходить из максимального размера пакета, доставка которого без фрагментации гарантируется IP-протоколом. А это 576 байт для IPv4, и 1280 для IPv6.
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных? AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Нет никакого различия. MTU не зависит от данных.
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Около 1% пакетов, если мы говорим о "большом интернете".
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP? AG>Как защититься от изменения порядка следования пакетов?
Здравствуйте, AlexGin, Вы писали:
AG>Имеется вот нейкая сетевая структура, где сервер и клиент связаны по TCP. AG>Межде сервером и клиентом поддерживается постоянное соединение (OS: Linux Ubuntu). AG>Предполагается, что эти сервер и клиент — отдельные машинки локальной сети.
AG>Вопрос: какова максимальная длина пакета, который НЕ будет разбиваться сетью на более мелкие пакеты? AG>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
MTU это размер пакета. Из них полезный payload для TCP будет, ессно, меньше (заголовки тоже требуют место).
MTU бывает разный. Всякие Cisco любят какие-то дикие размеры, типа 1200 с копейками
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Если в сети возникнут какие-то перебои и пакеты потеряются, то будут посланы повторно.
Если маршрутизация может поменяться, часть пакетов пойдет другим путём, то есть вероятность смены порядка.
Только если ты работаешь с TCP на прикладном уровне, то это не твоя задача. К тебе приходит упорядоченный поток.
AG>Вышеуказанные данные получены экспериментально. AG>При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
На то он и фуфельный девайс.
AG>P.S. Конечно же, я предусмотрел на стороне приёма, накопление сегментов_пакета — восствновление исходного пакета. AG>Оно основано на поиске 32-х битного маркера конца пакета.
Ты пытаешься сделать собственный WireShark или что?
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP? AG>Как защититься от изменения порядка следования пакетов?
Всё уже украдено придумано до вас.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый vsb, Вы писали:
vsb>>TCP не оперирует пакетами. TCP это поточный протокол. AG>+100500 AG>Да, может я и неправильно назвал данную сущность, но для моей задачи — характерны блоки данных (которые я назвал пакетами).
Я бы не советовал смешивать пакеты на уровне протокола и пакеты на уровне IP. Да, если пишешь 500 байтов в сокет и больше ничего не делаешь, то скорей всего они так и приедут в одном IP-пакете (с прицепленными TCP и IP заголовками). Но на "скорее всего" полагаться нельзя. В общем случае это сущности разные. Может и в одном IP пакете быть куча пакетов протокола. Может быть и наоборот.
AG>>>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
vsb>>MTU это размер IP пакета. AG>То есть — для уровня TCP, это значение может оказаться лишённое смысла...
Ну с ним мало что можно сделать, с этим значением. Преобразованием потока байтов в IP пакеты занимается операционная система, приложение тут ни на что влиять не может.
AG>>>MTU равный примерно 1.5 KBytes — это для произвольных данных? AG>>>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
vsb>>Размер IP пакета не зависит от того, какого рода данные в него кладут. Это гораздо более низкий уровень абстракции. AG> AG>Эту теорию я знаю уже не первый год. Вот почему же на практике иначе?
Что именно на практике иначе, я не совсем понимаю? Как меряете?
vsb>>При использовании TCP обо всех проблемах заботится операционная система. Программисту про это думать нужды нет.
AG>Это только в теории... AG>Впрочем, я также думал до недавнего времени. Пока не столкнулся с ситуацией: AG>Когда сервер и клиент — на одном и том же компе — всё работает как швейцарские часы. AG>Но вот если сервер и клиент — соединены проводом и через хаб — как это в реальной жизни — то тут начинается практика...
На практике в TCP протоколе может рваться соединение, потому, что какая-нибудь дурацкая коробка посредине так решила. Чтобы в TCP-протоколе терялись байты или приходили не в том порядке — такого быть не может. Ну т.е. понятно, что если коробка посредине зловредная, то всё может быть, но обычно в реальной жизни зловредных коробок нет. И скорей всего баг в вашем коде, который не проявляется при очень быстрой сети (на локалхосте скорость практически бесконечная) и проявляется в реальной сети. Например частая ошибка — люди всё же трактуют TCP как пакетный протокол, хоть он и поточный. Думают, что если записали в него тысячу байтов, то на другом конце чтение вернёт все эти тысячу байтов. А не факт. Оно может возвращать тысячу раз по одному байту. Т.е. понятно, что в конечном счёте все байты придут и прочитаются, но вот именно read совершенно не обязан читать весь пакет целиком. Это я пытаюсь играть в оракула по косвенным данным определяя баг (: Может быть даже угадаю.
Здравствуйте, AlexGin, Вы писали:
AG>1) Система работает в специальной сети (не общего пользования), так что шутники — курят в сторонке. AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта
Не парься о фрейминге, решай задачу прикладного уровня. Возьми какую-нибудь либу вроде protobuf (или никсмановский yas), накрути её поверх своей сетевой инфрастурктуры QT-шной и забудь про фрейминги. Либо поищи в QT что-то своё, я думаю у них есть под это дело что-то.
Здравствуйте, AlexGin, Вы писали:
Pzz>>А зачем сначала анонсировать наличие блока, а лишь потом его посылать? Что добавляет предварительная договоренность, кроме сложности?
AG>Передающая сторона имеет уверенность, что на приемной стороне готовы принять блок данных. AG>Добавляет сложности — есть такое немного
Выкинь ты это нахрен, оно не нужно. И добавь лучше периодические "пинги" в состоянии простоя — TCP keepalive с этим не очень хорошо справляется.
AG>2) Да, есть тот фактор, что я привязаываю проект к фреймворку Qt. К наиболее богатому и продвинутому из имеющихся на сегодня C++ фреймворков.
Ты понимаешь разницу между СПЕЦИФИКАЦИЕЙ протокола, и его РЕАЛИЗАЦИЕЙ? Нет ничего плохого в том, чтобы привязать реализацию к какому-либо фреймворку. Все равно, на чем-то реализовывать надо. Но вот спецификацию лучше бы сохранить нейтральной по отношению к языкам и фреймворкам.
Здравствуйте, AlexGin, Вы писали:
AG>Имеется вот нейкая сетевая структура, где сервер и клиент связаны по TCP. AG>Межде сервером и клиентом поддерживается постоянное соединение (OS: Linux Ubuntu). AG>Предполагается, что эти сервер и клиент — отдельные машинки локальной сети.
AG>Вопрос: какова максимальная длина пакета, который НЕ будет разбиваться сетью на более мелкие пакеты?
TCP не оперирует пакетами. TCP это поточный протокол.
AG>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
MTU это размер IP пакета.
AG>MTU равный примерно 1.5 KBytes — это для произвольных данных? AG>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
Размер IP пакета не зависит от того, какого рода данные в него кладут. Это гораздо более низкий уровень абстракции.
AG>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Если речь об IP, то ненулевая и зависит от типа сети. Например в WiFi это обычное дело, как и пропавшие пакеты, дубликаты и тд.
AG>Но меня интересует вопрос — как сеть дробит пакеты TCP? AG>Как защититься от изменения порядка следования пакетов?
При использовании TCP обо всех проблемах заботится операционная система. Программисту про это думать нужды нет. В каком порядке байты уходят в сокет с одной стороны, в том порядке придут с другой стороны.
Здравствуйте, AlexGin, Вы писали:
Pzz>>А что ты будешь делать, если у тебя эти четыре байта разрезались между двумя фрагментами? AG>То есть — последний фрагмент — менее 4-х байт? Воообще — возможно ли это?
Конечно возможно.
AG>После этого делать "накопление" данных, но критерием окончания накопления — делать не маркер конца, AG>а факт совпадения длины с заранее заявленной.
Да. А маркер конца становится ненужным.
Pzz>>И ты сразу подрезал себе возможность посылать запросы не по одному, а сразу пачками, а потом получить пачку ответов. AG> AG>Это протокол обмана сообщениями, или базар
Это называется request pipelining. Полезная штука, если скорость начинает упираться в round-trip time, а не в пропускную способность канала.
AG>Как я уже упоминал, в рамках одной сессии работает пара: Сервер + конкретный_Клиент. AG>Скорость обмена — устраивает Заказчика. Зачем делать такое ненужное усложнение?
У тебя есть логический уровень, который отображает твои сообщения, имеющие начало и конец, на поток байтов, которым является TCP (назовем этот уровень framing), и логический уровень, который определяет, что сообщения ты будешь использовать в режиме запрос-ответ. А ты взял, и смешал эти два логических уровня.
M>>Никто при использовании TCP в здравом уме не защищается
Pzz>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
У тебя вместе с tcp 3-4 уровня (физический, Ethernet(может не быть), IP, TCP) и на каждом своя контрольная сумма. Это как должен шуметь канал, чтобы данные по нему все же бегали, но иногда на всех 4-х уровнях контрольные суммы все же совпадали.
Тут я соглашусь, что защищаться от случайного искажения данных на уровне TCP смысла нет. Только если будет умышленная подмена (не случайная) — тогда нужно считать криптографический MAC (HMAC, например). Но в таком случае возникает задача обмена ключами для проверки MAC, потому что обычный HASH злоумышленник тоже сможет подменить. Однако, такое проще завернуть в известный протокол типа TLS, чем придумывать что-то самому.
Здравствуйте, Pzz, Вы писали:
N>>Начинает с MTU исходящего интерфейса и корректирует по поступлению ICMP needfrag сообщений. Это во всех стеках. В Linux, да, есть дополнительный режим "если та сторона не подтверждает — пробуем уменьшать размер нагрузки".
Pzz>Я не стал рассказывать про MTU path discovery, чтобы чрезмерно не переусложнять тему.
Можно было вынести в сноску. Совсем это игнорировать нежелательно — обычно именно где-то посредине дороги и возникают туннели с урезанным MTU.
Pzz>Я где-то читал, что эти needfrag не всегда доходят и не всегда посылаются, поэтому с ними бывают всякие разные проблемы. Не помню, включен ли MTU path discovery в линухе по умолчанию, а проверять лень...
Включен. Не всегда посылаются — да, бывает, но последние лет 10 я про такое уже не слышал. Может, даже самые тупые и ленивые наконец починились...
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
AG>Ты не поверишь, уважаемый Pzz, но в перспективе я бы хотел и от этого защититься. Ну а пока — вроде как не актуально.
Если используется свой протокол прикладного уровня — добавь в него контрольную сумму.
Здравствуйте, AlexGin, Вы писали:
AG>Да, передавать полный размер в нвчале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
В протоколе TCP не может быть потерянных пакетов. Восстановление последовательности выполняется на нижнем уровне.
На твоём прикладном уровне все пакеты на месте и в нужном порядке.
SVZ>>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано. SVZ>>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
AG>Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
Там всё немного сложнее. Подтверждаться может не каждый пакет, а целая цепочка.
SVZ>>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза. SVZ>>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
AG>Вот это интересно. AG>Где подробнее об этом почитать? Какие ключевые слова гуглить?
setsockopt
AG>Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?
Какая-нибудь ручка наружу обязательно торчит.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, уважаемый Stanislav V. Zudin, Вы писали:
SVZ>В протоколе TCP не может быть потерянных пакетов. Восстановление последовательности выполняется на нижнем уровне. SVZ>На твоём прикладном уровне все пакеты на месте и в нужном порядке.
+100500
Я в курсе, что теория говорит об этом. Практика иногда может и отличаться
SVZ>Там всё немного сложнее. Подтверждаться может не каждый пакет, а целая цепочка.
На моей (прикладной) стороне — обеспечена передача квитирования в сторону сервера, когда на клиенте приняли пакет (ну или же собрали из фрагментов)
и результат визуализировали для юзера.
SVZ>Какая-нибудь ручка наружу обязательно торчит.
Может вот это самое то: QAbstractSocket::setSocketOption QAbstractSocket::SendBufferSizeSocketOption
Здравствуйте, AlexGin, Вы писали:
vsb>>Если хочется железобетонный слой защиты, рекомендую HTTPS. Там и защищено всё так, что при всём желании не испортить ничего; и вопросы разбиения сообщений продуманы и реализаций в любом языке вагон и маленькая тележка. Я, конечно, понимаю, что всем нравится байты в сокете перекладывать, но с точки зрения практичности лично для меня нужны очень убедительные аргументы, чтобы НЕ использовать HTTP. AG> AG>Хорошо — при HTTP клиент играет роль активной стороны, то есть клиент инициирует обмен данными. AG>Что делать — если что-либо поменялось на_сервере (клиент не знает об этом факте)?
Ой всё
Да, тут сложней. Решение есть, даже два. Либо websockets, либо HTTP/2. Ну или делать polling, на самом деле тоже не самый плохой вариант. Но такое сам не пробовал и это уже посложней. Моя реплика в первую очередь относилась к модели запрос/ответ. Если нужно со стороны сервера инициировать сообщения, тут уже не всё так однозначно, соглашусь.
Здравствуйте, AlexGin, Вы писали:
AG>Что здесь не так? AG>Я использовал некоторое подмножество вариантов применения TCP. AG>Да, может возможно было бы более рационально использовать пропускную спрсобность канала. AG>Но это не имеет актуальности.
Не надо при проектировании framing'а полагаться на то, что фреймы эти будут использоваться строго в режиме вопрос-ответ. Ничего особо не выигрываешь, а лишь смешиваешь два логически не связанных уровня. О чем потом и пожалеешь.
Я даже не о пропускной способности канала сейчас говорю, а о логической целостности твоего протокола.
Здравствуйте, vsb, Вы писали:
vsb>Да, тут сложней. Решение есть, даже два. Либо websockets, либо HTTP/2. Ну или делать polling, на самом деле тоже не самый плохой вариант. Но такое сам не пробовал и это уже посложней. Моя реплика в первую очередь относилась к модели запрос/ответ. Если нужно со стороны сервера инициировать сообщения, тут уже не всё так однозначно, соглашусь.
О, так и знал, прочтя твое первое сообщение про HTTP, что дойдет и до новомодного HTTP/2
Что до вебсокета, он превращает HTTP в, практически, TCP-сокет с навешенным на него фреймингом. В терминах HTTP это называется protocol upgrade
Здравствуйте, AlexGin, Вы писали:
AG>Это только в теории... AG>Впрочем, я также думал до недавнего времени. Пока не столкнулся с ситуацией: AG>Когда сервер и клиент — на одном и том же компе — всё работает как швейцарские часы. AG>Но вот если сервер и клиент — соединены проводом и через хаб — как это в реальной жизни — то тут начинается практика...
В чём эта "практика"? Если вы учитываете, какими порциями смог прочитать recv() на приёмнике — вы уже успешно выстрелили себе в ногу. Не надо так.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, vsb, Вы писали:
vsb>>У IPv4 контрольная сумма защищает только заголовок. У IPv6 по-моему вообще её нет.
Pzz>Там две контрольные суммы. Одна защищает заголовок, другая — тело TCP-пакета. И обе одинаково паршивые.
1. Вот та, что защищает заголовок IP-пакета, в IPv6 отменена. Осталась контрольная сумма TCP.
2. Пусть паршивые, но их ортогональность типичной контрольной сумме Ethernet (которая CRC32-CCITT) очень помогает.
Здравствуйте, AlexGin, Вы писали:
SVZ>>На твоём прикладном уровне все пакеты на месте и в нужном порядке. AG>+100500 AG>Я в курсе, что теория говорит об этом. Практика иногда может и отличаться
Не отличается.
SVZ>>Там всё немного сложнее. Подтверждаться может не каждый пакет, а целая цепочка. AG>На моей (прикладной) стороне — обеспечена передача квитирования в сторону сервера, когда на клиенте приняли пакет (ну или же собрали из фрагментов)
Естественно, так как нет никакой гарантии, что пакеты доходят вообще. Посылка сообщения сервером не означает его доставку. TCP тут не причём.
) строятся велосипеды, вместо использования готовых блоков. Б>Причем с помощью очередей решаются все задачи автора — и распределение задач между серверами, и уведомление клиентов, и надежность передачи между узлами.
Тут автору надо объявить тендер. Уже прозвучало предложение сделать все по HTTP, по HTTP/2 и через вебсокеты. Ты предлагаешь очереди и брокер сообщений. Думаю, автору стоит озаботиться правильным выбором
P.S. Лично я бы выбирал между HTTP/1.1, если нет и не появится необходимости что-либо получать с сервера по инициативе сервера, и самодельным протоколом, если такая необходимость есть хотя бы в перспективе.
Здравствуйте, 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". Маркер конца есть? Есть. Пошли убивать, сообщение вполне однозначное
Имеется вот нейкая сетевая структура, где сервер и клиент связаны по TCP.
Межде сервером и клиентом поддерживается постоянное соединение (OS: Linux Ubuntu).
Предполагается, что эти сервер и клиент — отдельные машинки локальной сети.
Вопрос: какова максимальная длина пакета, который НЕ будет разбиваться сетью на более мелкие пакеты?
Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
Вопросы:
MTU равный примерно 1.5 KBytes — это для произвольных данных?
Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
ПРИМЕЧАНИЕ:
Данные насчёт показателя равного 14 KBytes (для текстовых данных) — взяты отсюда: https://tylercipriani.com/blog/2016/09/25/the-14kb-in-the-tcp-initial-window
Для общего случая — следует ориентироваться значением 1.5 KBytes.
Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
Вышеуказанные данные получены экспериментально.
При работе без сети (local-loopback) — просто на 127.0.0.1 — максимальная длина TCP пакета намного больше. Порядка 64 KBytes.
P.S. Конечно же, я предусмотрел на стороне приёма, накопление сегментов_пакета — восствновление исходного пакета.
Оно основано на поиске 32-х битного маркера конца пакета.
Но меня интересует вопрос — как сеть дробит пакеты TCP?
Как защититься от изменения порядка следования пакетов?
Но там теперь НЕ 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, Вы писали:
SVZ>Я подозреваю, ты немного о другой разбивке. SVZ>Т.к. это поток, то конца у него естественно нет. Только по своим признакам ты можешь определить, когда надо прекратить чтение. Либо передавать размер данных в начале, либо передавать какой-то маркер.
Да, передавать полный размер в начале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
SVZ>Размер кусков, вычитываемых за один раз из сокета, это вообще дело тёмное, отдано на откуп системе и с MTU никак не связано. SVZ>Скорость приема данных на уровне драйвера и скорость чтения прикладной программой из сокета разные, поэтому за одно чтение ты можешь зачитать сразу несколько пакетов.
Следующий пакет от сервера — не приходит, пока клиент не подтвердил (не квитировал) предшествующий.
SVZ>Максимум — ты можешь порулить размером буфера, выделяемого под сокет. В 99.9% дефолтных значений хватит за глаза.
А какие это значения?
SVZ>А размер буфера в прикладной программе — полностью под твоим контролем, хоть по одному байту читай.
Вот это интересно.
Где подробнее об этом почитать? Какие ключевые слова гуглить?
Ну и отдельный вопрос — возможно уже не к тебе — реализовано ли это как-то в Qt5?
Здравствуйте, уважаемый vsb, Вы писали:
vsb>TCP не оперирует пакетами. TCP это поточный протокол.
+100500
Да, может я и неправильно назвал данную сущность, но для моей задачи — характерны блоки данных (которые я назвал пакетами).
AG>>Правильно ли я понимаю, что эта длина определяется параметром MTU (когда вызываем команду ifconfig или netstat -ie в Linux)?
vsb>MTU это размер IP пакета.
То есть — для уровня TCP, это значение может оказаться лишённое смысла...
AG>>MTU равный примерно 1.5 KBytes — это для произвольных данных? AG>>Для текстовых данных этот показатель порядка 14 KBytes. Почему различие почти в десять раз?
vsb>Размер IP пакета не зависит от того, какого рода данные в него кладут. Это гораздо более низкий уровень абстракции.
Эту теорию я знаю уже не первый год. Вот почему же на практике иначе?
AG>>Насколько вероятна ситуация, что поменяется порядок следования пакетов? То есть — переданный в сеть позже, появится на приёме раньше.
vsb>Если речь об IP, то ненулевая и зависит от типа сети. Например в WiFi это обычное дело, как и пропавшие пакеты, дубликаты и тд
Вот это уже теплее!
vsb>При использовании TCP обо всех проблемах заботится операционная система. Программисту про это думать нужды нет.
Это только в теории...
Впрочем, я также думал до недавнего времени. Пока не столкнулся с ситуацией:
Когда сервер и клиент — на одном и том же компе — всё работает как швейцарские часы.
Но вот если сервер и клиент — соединены проводом и через хаб — как это в реальной жизни — то тут начинается практика...
Здравствуйте, AlexGin, Вы писали:
AG>При работе сессии — от сервера к клиенту может передаваться результат вычислений (пакет данных — сериализованных — размером до 10 KBytes). AG>Все остальные пакеты — относительно небольшие — от 10 байт до примерно 1...3 KByte. AG>Пакеты в 1...3 KByte — это JSON (они следуют от клиента к серверу). AG>Они определяют — что должен считать алгоритм бизнесс-логики на сервере.
Термин "пакет" в контексте разговоров о сети несколько перегружен. Я бы использовал "блок" или что-нибудь в этом роде.
AG>Тем не менее, исходный пакет вполне себе разбивается на небольшие фрагменты (что лично меня несколько удивило). AG>В общем — пришлось доработать так, чтобы была сборка пакета из фрагментов.
TCP, логически — это поток байтов. И когда ты отправляешь, скажем, 10 килобайт, то прийти они могут одним куском, а могут произвольным количеством кусков. Но в любом случае, они придут в том же порядке, в котором были отправлены.
Если тебе нужно, логически, пересылать данные блоками, с сохранением границ блоков, то надо предусмотреть какой-то свой механизм. Например, перед каждым блоком передается его длинна.
Здравствуйте, AlexGin, Вы писали:
AG>Да, передавать полный размер в начале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, AlexGin, Вы писали:
AG>>Я в курсе, что теория говорит об этом. Практика иногда может и отличаться
Pzz>Нет, не может. А твои слишком умные защиты замаскируют твои собственные ошибки, приводящие к потере данных.
может на практике когда сильно умные DPI или оборудование у прова которое не выдерживает транзита
если не сильно большой pps и не сильно заумный траффик
тогда можно не волноваться
Здравствуйте, уважаем ый Pzz, Вы писали:
Pzz>Нет, не может. А твои слишком умные защиты замаскируют твои собственные ошибки, приводящие к потере данных.
+100500
Вот чтобы этого избежать — я и создал данную тему!
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Термин "пакет" в контексте разговоров о сети несколько перегружен. Я бы использовал "блок" или что-нибудь в этом роде.
Ну пусть "блок" — кому легче/теплее
Pzz>TCP, логически — это поток байтов. И когда ты отправляешь, скажем, 10 килобайт, то прийти они могут одним куском, а могут произвольным количеством кусков. Но в любом случае, они придут в том же порядке, в котором были отправлены.
+100500
Вот это уже хорошо!!! Это отлично!
Pzz>Если тебе нужно, логически, пересылать данные блоками, с сохранением границ блоков, то надо предусмотреть какой-то свой механизм. Например, перед каждым блоком передается его длинна.
+100500
Хорошо, если я буду ориентироваться на длину, мне убирать мой_собственный маркер конца блока,
или же оставить, как дополнительную проверку валидности?
Здравствуйте, уважаемый reversecode, Вы писали:
R>может на практике когда сильно умные DPI или оборудование у прова...
Нет, это не тот случай — здесь нет ISP.
Здравствуйте, AlexGin, Вы писали:
Pzz>>Термин "пакет" в контексте разговоров о сети несколько перегружен. Я бы использовал "блок" или что-нибудь в этом роде. AG>Ну пусть "блок" — кому легче/теплее
Мне легче и теплее.
AG>+100500 AG>Хорошо, если я буду ориентироваться на длину, мне убирать мой_собственный маркер конца блока, AG>или же оставить, как дополнительную проверку валидности?
Что-то одно из двух убрать, или длину, или маркер конца. С длиной приемник будет эффективнее работать: не надо будет сканировать каждый байт в поисках маркера.
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Что-то одно из двух убрать, или длину, или маркер конца. С длиной приемник будет эффективнее работать: не надо будет сканировать каждый байт в поисках маркера.
Дело в том, что в Qt реализации TCP подсистемы имеет место генерация сигнала readyRead объектом типа QTcpSocket —
в тот самый момент, когда фрагмент (или блок) данных поступил на приёмник от дальнего_конца.
Я подписываюсь (своим слотом) на вышеуказанный сигнал.
Когда данный сигнал успешно отработал, ко мне приходит массив байтов типа QByteArray (его общая длина — известна).
Этот массив — может представлять собой целый блок (ну то-есть пользовательский_пакет) или же только его фрагмент.
Я же проверяю не все байты, а только четыре_последних_байта на маркер конца:
— если его нет, то помещаю этот массив в "накопитель" и жду недостающие фрагменты;
— если он есть — считаем что блок данных успешно принят — его можно применять.
Здравствуйте, AlexGin, Вы писали:
AG>Этот массив — может представлять собой целый блок (ну то-есть пользовательский_пакет) или же только его фрагмент. AG>Я же проверяю не все байты, а только четыре_последних_байта на маркер конца: AG>- если его нет, то помещаю этот массив в "накопитель" и жду недостающие фрагменты; AG>- если он есть — считаем что блок данных успешно принят — его можно применять.
Если удаленная сторона может отправить несколько блоков данных, то тебя ждёт неприятный сюрприз. К тебе в буфер они могут прийти вместе.
Стримы, мать их за ногу...
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, уважаемый Stanislav V. Zudin, Вы писали:
SVZ>Если удаленная сторона может отправить несколько блоков данных, то тебя ждёт неприятный сюрприз. К тебе в буфер они могут прийти вместе. SVZ>Стримы, мать их за ногу...
Я при разработке протокола обмена сделал так, чтобы новый блок данных отправлялся только после того,
как противоположная сторона приняла предшествующий блок (и передала нам квитирующий блок).
То есть — приведенный выше сценарий не реален. Даже для стримов.
Здравствуйте, AlexGin, Вы писали:
AG>Да, передавать полный размер в начале — также неплохая идея. Может стоит совместить это с маркером конца пакета? На случай потери промежуточных фрагментов, например.
О какой потере промежуточных пакетов в TCP идет речь?
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>А что ты будешь делать, если у тебя эти четыре байта разрезались между двумя фрагментами?
То есть — последний фрагмент — менее 4-х байт? Воообще — возможно ли это?
Впрочем, вопрос вполне резонный.
Возможно — правильнее было бы передавать длину всего блока (в начале блока).
После этого делать "накопление" данных, но критерием окончания накопления — делать не маркер конца,
а факт совпадения длины с заранее заявленной.
Pzz>И ты сразу подрезал себе возможность посылать запросы не по одному, а сразу пачками, а потом получить пачку ответов.
Это протокол обмана сообщениями, или базар
Как я уже упоминал, в рамках одной сессии работает пара: Сервер + конкретный_Клиент.
Скорость обмена — устраивает Заказчика. Зачем делать такое ненужное усложнение?
Здравствуйте, AlexGin, Вы писали:
AG>Теоретически — при этом или не совпадут контрольные суммы пакетов_нижнего_уровня или будет time-out. AG>Практически же — никто не знает.
Или отвалится, или нет. Других вариантов нет.
AG>Ну или же каждый разработчик прикладного ПО на_верхнем_уровне защищается от ситуации по-своему.
Никто при использовании TCP в здравом уме не защищается
Здравствуйте, Marty, Вы писали:
AG>>Ну или же каждый разработчик прикладного ПО на_верхнем_уровне защищается от ситуации по-своему.
M>Никто при использовании TCP в здравом уме не защищается
Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
M>Или отвалится, или нет. Других вариантов нет.
AG>Ну или же каждый разработчик прикладного ПО на_верхнем_уровне защищается от ситуации по-своему. M>Никто при использовании TCP в здравом уме не защищается
IMHO — это зависит от уровня ответственности ПО:
— многопользовательская сетевая игра — да в здравом уме никто не защищается от описанной ситуации!
— система управления движением самолётов в международном аэропорту...
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
Ты не поверишь, уважаемый Pzz, но в перспективе я бы хотел и от этого защититься. Ну а пока — вроде как не актуально.
Здравствуйте, AlexGin, Вы писали:
Pzz>>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
AG>Ты не поверишь, уважаемый Pzz, но в перспективе я бы хотел и от этого защититься. Ну а пока — вроде как не актуально.
Если хочется железобетонный слой защиты, рекомендую HTTPS. Там и защищено всё так, что при всём желании не испортить ничего; и вопросы разбиения сообщений продуманы и реализаций в любом языке вагон и маленькая тележка. Я, конечно, понимаю, что всем нравится байты в сокете перекладывать, но с точки зрения практичности лично для меня нужны очень убедительные аргументы, чтобы НЕ использовать HTTP.
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>Да. А маркер конца становится ненужным.
+100500
Здесь всё ясно и вполне логично.
Здесь я тебя понял и согласился с твоими аргументами.
Pzz>Это называется request pipelining. Полезная штука, если скорость начинает упираться в round-trip time, а не в пропускную способность канала.
Это поищу и подумаю — насколько мне это актуально.
Pzz>У тебя есть логический уровень, который отображает твои сообщения, имеющие начало и конец, на поток байтов, которым является TCP (назовем этот уровень framing), и логический уровень, который определяет, что сообщения ты будешь использовать в режиме запрос-ответ. А ты взял, и смешал эти два логических уровня.
Что здесь не так?
Я использовал некоторое подмножество вариантов применения TCP.
Да, может возможно было бы более рационально использовать пропускную спрсобность канала.
Но это не имеет актуальности.
Здравствуйте, уважаемый vsb, Вы писали:
vsb>Если хочется железобетонный слой защиты, рекомендую HTTPS. Там и защищено всё так, что при всём желании не испортить ничего; и вопросы разбиения сообщений продуманы и реализаций в любом языке вагон и маленькая тележка. Я, конечно, понимаю, что всем нравится байты в сокете перекладывать, но с точки зрения практичности лично для меня нужны очень убедительные аргументы, чтобы НЕ использовать HTTP.
Хорошо — при HTTP клиент играет роль активной стороны, то есть клиент инициирует обмен данными.
Что делать — если что-либо поменялось на_сервере (клиент не знает об этом факте)?
Здравствуйте, Reset, Вы писали:
Pzz>>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
R>У тебя вместе с tcp 3-4 уровня (физический, Ethernet(может не быть), IP, TCP) и на каждом своя контрольная сумма. Это как должен шуметь канал, чтобы данные по нему все же бегали, но иногда на всех 4-х уровнях контрольные суммы все же совпадали.
У IPv4 контрольная сумма защищает только заголовок. У IPv6 по-моему вообще её нет.
Здравствуйте, Reset, Вы писали:
R>У тебя вместе с tcp 3-4 уровня (физический, Ethernet(может не быть), IP, TCP) и на каждом своя контрольная сумма. Это как должен шуметь канал, чтобы данные по нему все же бегали, но иногда на всех 4-х уровнях контрольные суммы все же совпадали.
Ну, на физическом уровне контрольной суммы обычно нет. Поэтому если на уровне Ethernet контрольная сумма почему-то отсутствует, то остается только паршивенькая контрольная сумма TCP.
R>Тут я соглашусь, что защищаться от случайного искажения данных на уровне TCP смысла нет. Только если будет умышленная подмена (не случайная) — тогда нужно считать криптографический MAC (HMAC, например). Но в таком случае возникает задача обмена ключами для проверки MAC, потому что обычный HASH злоумышленник тоже сможет подменить. Однако, такое проще завернуть в известный протокол типа TLS, чем придумывать что-то самому.
Здравствуйте, Pzz, Вы писали:
Pzz>MTU — это параметр сетевого интерфейса, который определяет максимальный размер пакета (все равно какого, TCP, UDP, ICMP...), который не будет фрагментироваться при отправке через этот интерфейс.
Для TCP важен минимальный из всех MTU по дороге.
Pzz>TCP, естественно, не хочет, чтобы его пакеты фрагментировались. Поэтому при соединении по локальной сети TCP будет ориентироваться на MTU, за вычетом служебных данных. А вот если соединение нелокальное, то у TCP нет знаний о том, как будет происходить фрагментация на промежуточных узках. Поэтому он будет исходить из максимального размера пакета, доставка которого без фрагментации гарантируется IP-протоколом. А это 576 байт для IPv4, и 1280 для IPv6.
Начинает с MTU исходящего интерфейса и корректирует по поступлению ICMP needfrag сообщений. Это во всех стеках. В Linux, да, есть дополнительный режим "если та сторона не подтверждает — пробуем уменьшать размер нагрузки".
Здравствуйте, netch80, Вы писали:
N>Начинает с MTU исходящего интерфейса и корректирует по поступлению ICMP needfrag сообщений. Это во всех стеках. В Linux, да, есть дополнительный режим "если та сторона не подтверждает — пробуем уменьшать размер нагрузки".
Я не стал рассказывать про MTU path discovery, чтобы чрезмерно не переусложнять тему.
Я где-то читал, что эти needfrag не всегда доходят и не всегда посылаются, поэтому с ними бывают всякие разные проблемы. Не помню, включен ли MTU path discovery в линухе по умолчанию, а проверять лень...
Здравствуйте, Reset, Вы писали:
R>P.P.S. У TCP есть включенный по умолчанию алгоритм минимизации количества пакетов (гуглить по "TCP_NODELAY"). Когда TCP пакет сформирован не целиком (записали 10 байт, например, а в TCP пакет влезает 1460, или записали 10K и в последнем пакете еще осталось место), то пакет ждет несколько ms, вдруг появятся еще данные, чтобы их тоже отправить в том же пакете (целиком сформированные пакеты пойдут в сеть сразу, им нет смысла ждать). Тебе, возможно, полезно отключить эту задержку, чтобы при записи в сеть блока данных, он тут же начал отправляться без задержки.
Вроде бы, современные TCP-стеки понимают, что если после одного или нескольких send() сказали recv(), то можно больше и не задерживать хвост последнего пакета, все равно, пока recv() чего-нибудь не вернет, send()ов больше не будет.
Здравствуйте, уважаемый netch80, Вы писали:
N>В чём эта "практика"? Если вы учитываете, какими порциями смог прочитать recv() на приёмнике — вы уже успешно выстрелили себе в ногу. Не надо так.
Ну хорошо — я накопил данные от первого recv(), затем следующего и т.д — пока не уяснил что блок_пользовательских_данных принят весь.
Блок_пользовательских_данных — это тот полный набор данных, что следует от сервера к клиенту.
Таким образом, если при передаче по сети его разбило на несколько частей, то я их могу "накопить" и соединить вместе.
Так нормально?
Здравствуйте, Pzz, Вы писали:
vsb>>У IPv4 контрольная сумма защищает только заголовок. У IPv6 по-моему вообще её нет.
Pzz>Там две контрольные суммы. Одна защищает заголовок, другая — тело TCP-пакета. И обе одинаково паршивые.
Здравствуйте, Pzz, Вы писали:
vsb>>Где?
Pzz>Вторая — Тут
Не так прочитал, думал, ты про то, что IP пакет защищает тело контрольной суммой. В общем я к тому, что в TCP одна контрольная сумма, а не несколько, поэтому она и вправду не стопроцентно надёжная. Насчёт транспортного протокола не знаю, с ними не сталкивался.
Здравствуйте, netch80, Вы писали:
N>Теперь надо решить, как определять, что передача от сервера закончилась (а для сервера — аналогично от клиента). Есть разные стили фрейминга для этого. Например, один из классических — вначале идёт длина всей посылки в двоичном виде (например, 4 байта в network order == big-endian). Но можно придумать тысячи других по вкусу.
Главное не забыть, что длина тоже может прийти кусками И хорошо бы её проверять, прежде чем выделять буфер указанного размера, а то придёт 4 миллиарда от шутника какого-нибудь. 4 гигабайта пока ещё ощутимый объём памяти.
Здравствуйте, vsb, Вы писали:
vsb>Не так прочитал, думал, ты про то, что IP пакет защищает тело контрольной суммой. В общем я к тому, что в TCP одна контрольная сумма, а не несколько, поэтому она и вправду не стопроцентно надёжная. Насчёт транспортного протокола не знаю, с ними не сталкивался.
Ну, она CRC32. В массштабах 4-гигабайтного кино вероятность пропустить одиночную ошибку больше половины. С другой стороны, кто его качает, кино, по голому TCP?
Здравствуйте, Pzz, Вы писали:
AG>>>Ну или же каждый разработчик прикладного ПО на_верхнем_уровне защищается от ситуации по-своему.
M>>Никто при использовании TCP в здравом уме не защищается
Pzz>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
Могу предположить, что у такого "шумного канала" есть свои механизмы контроля целостности данных, которые расположены ниже уровня IP. В противном случае, имхо, такой канал никому не нужен будет.
Так, у Ethernet'а, например, есть ещё CRC32 кадра
Здравствуйте, уважаемый vsb, Вы писали:
vsb>Главное не забыть, что длина тоже может прийти кусками И хорошо бы её проверять, прежде чем выделять буфер указанного размера, а то придёт 4 миллиарда от шутника какого-нибудь. 4 гигабайта пока ещё ощутимый объём памяти.
1) Система работает в специальной сети (не общего пользования), так что шутники — курят в сторонке.
2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта
Здравствуйте, AlexGin, Вы писали:
vsb>>Главное не забыть, что длина тоже может прийти кусками И хорошо бы её проверять, прежде чем выделять буфер указанного размера, а то придёт 4 миллиарда от шутника какого-нибудь. 4 гигабайта пока ещё ощутимый объём памяти. AG> AG>1) Система работает в специальной сети (не общего пользования), так что шутники — курят в сторонке. AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта
Имеется в виду вариант типа такого:
вызвали recv() — пришло, например, 1460 байт (типовой MSS на Ethernet без timestamp-опций).
Из них 1458 — первое сообщение с заголовком длины. А ещё 2 — начало заголовка длины второго сообщения.
Теперь надо эти 2 сохранить, ответ следующего recv() дописать к ним и уже тогда декодировать длину.
Здравствуйте, уважаемый netch80, Вы писали:
AG>2) Под длину блока — выделяется четыре первых байта принятого массива — какой тебе кусок на менее, чем четыре байта
N>Имеется в виду вариант типа такого: N>вызвали recv() — пришло, например, 1460 байт (типовой MSS на Ethernet без timestamp-опций). N>Из них 1458 — первое сообщение с заголовком длины. А ещё 2 — начало заголовка длины второго сообщения. N>Теперь надо эти 2 сохранить, ответ следующего recv() дописать к ним и уже тогда декодировать длину.
Как я уже упоминал: следующий блок (пакет_пользовательского_уровня) — у нас ждёт.
Ждёт, пока не отработает предшествующий блок. Так я задумал и реализовал протокол верхнего (прикладного) уровня.
Посему, указанная Вами, уважаемый netch80, ситуация (с двумя байтами от нового блока) невозможна в принцыпе.
Да, я в курсе — что не использовал все возможности 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, Вы писали:
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 проверяется "под_капотом"...
Здравствуйте, AlexGin, Вы писали:
Pzz>>Не надо при проектировании framing'а полагаться на то, что фреймы эти будут использоваться строго в режиме вопрос-ответ. Ничего особо не выигрываешь, а лишь смешиваешь два логически не связанных уровня. О чем потом и пожалеешь. AG>Ну OK — чтобы заполнить канал передачи, помимо диалога Server-Client будем передавать фильмы. AG>Или торрент-сеть организуем AG>Вот не знаю — что выбрать?
Не надо заполнять посторонними данными. Но и в прямом применении может оказаться необходимо:
1. Посылать несколько запросов от клиента сразу, чтобы, пока они ползут по сети, сервер мог их отрабатывать. Обычно это называется pipelining.
2. Делать, что сервер отвечает на один запрос несколькими ответами — например, сначала "принял, исполняю", потом "прогресс 50%, полёт нормальный", потом "завершил, вот финальные результаты", с интервалом в минуты между ответами. В таком случае нужно ожидать ответов сервера в произвольные моменты и давать сообщениям теги, связывая ответы с запросами.
3. Передавать внеочередные нотификации с каждой стороны о каких-то важных изменениях или о том, на что другая подписалась.
4. Уравнять роли клиента и сервера — два равноправных участника что-то делают и могут начать новые действия в любой момент.
Если что-то из этого может происходить — потребуется или менять протокол, или заранее подготовить его к такому расширению.
Pzz>>Я даже не о пропускной способности канала сейчас говорю, а о логической целостности твоего протокола. AG>Мой протокол — это "разговор" двух человек аппаратно-программных сущностей: сервер и клиент... AG>Что предлагается как альтернатива диалогу — передача "пустого" space-holder-а, пока требуемого контента не насобиралось?
Здравствуйте, уважаемый Marty, Вы писали:
... M>И какая тут принципиальная разница?
...
Блок в 10 байт — войдёт всегда и фактически без доп-проверок.
Чего совсем не сказать о блоке в 10 килобайт.
P.S. Проблему удалось решить — за счет контроля длины блоков.
Предыдущее решение — за счёт маркёра конца — не такое изящное и (по совету уважаемого товарища Pzz) я отказался от него.
Ранее (ещё вчера) было так:
AG>Этот массив — может представлять собой целый блок (ну то-есть пользовательский_пакет) или же только его фрагмент. AG>Я же проверяю не все байты, а только четыре_последних_байта на маркер конца: AG>- если его нет, то помещаю этот массив в "накопитель" и жду недостающие фрагменты; AG>- если он есть — считаем что блок данных успешно принят — его можно применять.
Теперь:
Передаю четыре байта длины блока — в первых четырех октетах, при приёме нового блока — анализирую совпадает ли общая длина,
с объявленной в первой четвёрке байт.
— если совпадает, то считаем что блок принят и проводим его дальнейшую обработку/визуализацию;
— если не совпадает, то продолжаем заполнять "накопитель" (пока общая длина накопленного не совпадёт с объявленной в начале блока).
Прикладной протокол в моей системе выглядит так:
Это пример передачи — от клиента к серверу (в обратном направлении — всё то же самое, только клиент и сервер меняются местами):
-------------------------------------------------------------------------------------------------------------------
CLIENT's side | SERVER's side | Comments
-------------------------------------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------------------------------------------
Marker_1,_2,_3 — это простые 10-ти байтные посылки (здесь проблем нет), а вот {User's-Packet} — ну точнее "блок_данных" — большой.
Были случаи, что около 30 килобайт (на JSON-варианте), теперь — с сериализацией через QDataStream — удалось выйти на размер менее 10 килобайт.
Здравствуйте, AlexGin, Вы писали:
AG>Прикладной протокол в моей системе выглядит так: AG>Это пример передачи — от клиента к серверу (в обратном направлении — всё то же самое, только клиент и сервер меняются местами):
А зачем сначала анонсировать наличие блока, а лишь потом его посылать? Что добавляет предварительная договоренность, кроме сложности?
AG>Были случаи, что около 30 килобайт (на JSON-варианте), теперь — с сериализацией через QDataStream — удалось выйти на размер менее 10 килобайт.
А у этого QDataStream унутренность документирована? Не получится ли так, что теперь вы к Qt намертво привязаны в т.ч. форматом данных?
Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>А зачем сначала анонсировать наличие блока, а лишь потом его посылать? Что добавляет предварительная договоренность, кроме сложности?
Передающая сторона имеет уверенность, что на приемной стороне готовы принять блок данных.
Добавляет сложности — есть такое немного
Добавляет уверенности, что в случае большой загрузки CPU приёмной стороны, передающая "повременит" с отправкой основного пакета,
дожидаясь, пока на приёмной стороне не закончиться выполнение предшествующей задачи и не освободятся вычислительные мощности.
AG>>Были случаи, что около 30 килобайт (на JSON-варианте), теперь — с сериализацией через QDataStream — удалось выйти на размер менее 10 килобайт.
Pzz>А у этого QDataStream унутренность документирована? Не получится ли так, что теперь вы к Qt намертво привязаны в т.ч. форматом данных?
1) Исходники всего Qt имеются и разобраться с ними (для специалиста, знакомого с C++) не составит большого труда.
2) Да, есть тот фактор, что я привязаываю проект к фреймворку Qt. К наиболее богатому и продвинутому из имеющихся на сегодня C++ фреймворков.
Этот момент также даёт дополнительные бонусы:
— мне и администрации нашей конторы легче найти новых девелоперов на проект. Т.к. C++ и Qt популярны в условиях минского рынка IT;
— при разработке на Qt легче найти ответы на вопросы (чем на более экзотических новомодных языках/технологиях);
— в едином стиле можно разрабатывать весь комплекс ПО: клиент, сервер, Data-base layer и т.д.
) строятся велосипеды, вместо использования готовых блоков.
Причем с помощью очередей решаются все задачи автора — и распределение задач между серверами, и уведомление клиентов, и надежность передачи между узлами.
Еше не начали разрабатывать сами клиенты и серверы, но зачем-то углубились в транспорт, хотя он, похоже, не является узким местом.
Вот я и спрашиваю, зачем протокол, зачем писать свой брокер сообщений? Чем не устраивают имеющиеся варианты?
Здравствуйте, уважаемый Pzz, Вы писали:
AG>>Передающая сторона имеет уверенность, что на приемной стороне готовы принять блок данных. AG>>Добавляет сложности — есть такое немного
Pzz>Выкинь ты это нахрен, оно не нужно. И добавь лучше периодические "пинги" в состоянии простоя — TCP keepalive с этим не очень хорошо справляется.
Выкидывать — не надо, это годная фича. Я уже сообщал, для чего она предназначена.
Добавить ping-и: на перспективу неплохо, я и сам думал об этом.
Но на данном этапе — это как раз выглядит усложнением. Предполагаю, что с этим можно и подождать.
AG>>2) Да, есть тот фактор, что я привязаываю проект к фреймворку Qt. К наиболее богатому и продвинутому из имеющихся на сегодня C++ фреймворков.
Pzz>Ты понимаешь разницу между СПЕЦИФИКАЦИЕЙ протокола, и его РЕАЛИЗАЦИЕЙ? Нет ничего плохого в том, чтобы привязать реализацию к какому-либо фреймворку. Все равно, на чем-то реализовывать надо. Но вот спецификацию лучше бы сохранить нейтральной по отношению к языкам и фреймворкам.
Так спецификация — она и есть нейтральна.
Хочешь — делай на POSIX, хочешь — на STL/boost, хочешь — на Python.
Лично мне нравится для этого применять именно Qt.
P.S. Данную тему можно считать исчерпанной. Вам, уважаемый Pzz, большая благодарность за участие и подсказки.
На данный момент — я ушёл от выявления маркера конца и работаю по длине блока, передаваемой в начале блока.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Pzz, Вы писали:
Pzz>>Ну строго говоря, у TCP очень паршивая контрольная сумма. Если гнать большие объемы данных по шумному каналу, данные иногда будут приходить попорченными. Но ТС вряд ли именно от этого защищается.
AG>Ты не поверишь, уважаемый Pzz, но в перспективе я бы хотел и от этого защититься.
HMAC — контроль приолжением целостности данных как для зашумления, так и для злонамеренного искажения данных. А если сверху TLS как средство транспортного шифрования навернуть (как HTTPS делает) — так вообще красота.
Здравствуйте, netch80, Вы писали:
Pzz>>Я где-то читал, что эти needfrag не всегда доходят и не всегда посылаются, поэтому с ними бывают всякие разные проблемы. Не помню, включен ли MTU path discovery в линухе по умолчанию, а проверять лень...
N>Включен. Не всегда посылаются — да, бывает, но последние лет 10 я про такое уже не слышал. Может, даже самые тупые и ленивые наконец починились...
Если гейт посередине закрывает/зацикливает ICMP (например, для защиты от флуд-атак или как одно из мероприятий по усложнению сканирования структуры сети), то будет резать весь ICMP даже если стороны посылают друг другу fragmentation-инструкции.
Здравствуйте, 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, а может, и таки что-то своё изобретать поверх.
