гарантированная доставка данных в tcp осуществляется за счет
Гарантированнная доставка сообщения по протоколу TCP
Всем привет. Уже несколько дней ломаю голову над одной проблемой. Как то раз нашёл пример многопользовательского клиент-серверного консольного TCP чата. И если я не ошибаюсь, то протокол TCP не гарантирует доставку сообщения. И в случае если сообщение не будет доставлено полностью или доставлено вообще, то надо предпринять какие-то меры. Данная программа если я не ошибаюсь, не предпринимает никаких действий если сообщения не будет доставлено полностью.
Вопрос: Какие меры надо предпринять чтобы обеспечить гарантированную доставку сообщения или же, что надо делать если сообщения не будет доставлено полностью? Или может быть программа принимает какие либо меры, если сообщение не будет доставлено полностью? Если не трудно, то покажите,что надо добавить в программу.
Программа имеет 2 проекта Клиент и Сервер.
Код Клиента:
Класс Program:
Код Сервера:
Класс ServerObject:
Пытался сделать так как посоветовал PashaPash, но всё без результатно.
Как мне посоветовал PashaPash я добавил признак окончания сообщения ‘/’
Если я правильно понял данные должны считываться как-то с помощью StreamReader Но как накапливать данные в MemoryStream не очень понятно?
1 ответ 1
TCP гарантирует доставку.
Проблема в вашем коде в том, что он предполагает, что то, что передано в один вызов Write, будет вычитано одним вызовом Read на другой стороне. А это не так.
Write не «отправляет пакет». Он просто пишет данные в сокет.
А Read не «читает пакет». Он вычитывает из буфера сокета то, что успело дойти.
Надежные способы, на выбор:
Пример на коде из вопроса (с минимальными изменениями):
Реализация гарантированной асинхронной доставки сообщений
Статья за авторством Александра Романова, разработчика интеграционных решений.
В процессе интеграции систем мы часто сталкиваемся с необходимостью гарантированной доставки сообщений между системами. В таких случаях на помощь нам приходят очереди. Но не все задачи так просты, как доставка сообщений из системы А в систему Б. Бывают случаи, когда нужно обогатить доставляемые сообщения данными из смежных, участвующих в интеграции систем. Которые не всегда могут интегрироваться через очереди, а имеют лишь синхронные сервисы. И вот уже в нашей интеграции возникают такие явления, как недоступность, отказы и другие «приятные» особенности использования «синхронов». Можно было бы переложить обработку промежуточных отказов на систему-источник, но это некультурно, да и невозможно, если мы публикуем события сразу для нескольких систем (в топик).
Удобным и работающим решением проблемы, с нашей точки зрения, является асинхронная пошаговая обработка сообщения через внутреннюю очередь с вызовом внешнего сервиса на каждом шаге. В случае отказа сервиса по ошибке или из-за его временной неработоспособности сообщение попадает во внутреннюю очередь отказов и отправляется повторно после разборов с возникшими в сервисе проблемами.
Данное решение так же устраняет проблему невозможности отката транзакции при работе с внешними сервисами. Никакой вызов не пройдет дважды — обработка начинается именно с того шага, на котором произошел сбой.
Всё вышеописанное очень легко реализуется на интеграционной шине, в которой асинхронное взаимодействие между компонентами через внутренние очереди идёт «из коробки». Но слишком высокие цены за «коробку» могут сильно затруднить использование интеграционной шины. Мы приведем пример реализации простого приложения на Spring Integration (далее SI) + Rabbit MQ. Оговоримся, что Rabbit MQ у себя в production мы не используем из-за невозможности его работы с XA.
Сердцем всего приложения является spring-integration-context.xml. Там описана компонентная модель, инициализируются ресурсные бины и менеджер транзакций для работы с MQ. Опишем его подробнее.
Подключаем встроенный в SI драйвер и прописываем ресурсы:
Нам необходим низкоуровневый бин amqpTemplate, через который осуществляется взаимодействие с ресурсами. Данный бин мы используем напрямую в тестах, и он требуется для компонент SI, которые работают с Rabbit MQ. ConnectionFactory, необходимый для подключения к ресурсам, конфигурит Spring Boot по настройкам из application.yml (см. org.springframework.boot.autoconfigure.amqp.RabbitAutoConfiguration).
Для транзакционной работы с Rabbit MQ требуется TransactionManager (нужен для отката сообщения обратно в очередь, если в процессе работы произойдет ошибка). К сожалению, Rabbit MQ не поддерживает XA-транзакции, иначе менеджер транзакций сконфигурил бы Spring Boot. Конфигурим предоставляемый Spring-ом вручную.
А теперь самое приятное. «Рисуем» flow! В кавычках, потому что пишем в виде xml, что менее приятно.
Рассмотрим сценарий взаимодействия между двумя компонентами. SomeComponentOne получает сообщение из канала, вызывает некий синхронный REST-сервис (работает с БД, пишет в файл и т.п.) и отправляет сообщение на дальнейшую обработку, которой должна заниматься SomeComponentTwo. Если SomeComponentOne не смогла выполнить порученный ей кусок работы, она должна откатить транзакцию и вернуть полученное сообщение туда, откуда она его забрала. Если всё хорошо — отправить сообщение во внутреннюю очередь и завершить транзакцию. SomeComponentOne забирает сообщение из внутренней очереди и отправляет сообщение в неё же, при этом не обязательно в том же виде, в котором получила. Сообщение может быть обогащено или изменено, нам не важно. Оно предназначено для работы компоненты SomeComponentTwo. Возникает проблема роутинга. Сообщение попадает во внутреннюю очередь и должно забираться оттуда нужной в данный момент времени компонентой. Другими словами, необходим роутинг.
В данном приложении продемонстрирован роутинг, основанный на заголовках сообщения. У сообщения заполняется кастомный заголовок PartnerComponent, указывающий на компоненту, которая должна работать с сообщением.
Распишем технические детали представленного flow.
Адаптер для чтения из входной очереди. Получает сообщение и в транзакции бросает его сразу во внутреннюю очередь.
Мы использовали специализированный для работы с очередями асинхронный канал, предоставляемый Spring-ом. Получили интерфейс SI-channel, а хранение сообщений непосредственно в очереди, в нашем случае во внутренней mq-очереди приложения. При получении сообщения из данного канала-очереди будет открываться транзакция, т.к. мы подключили наш менеджер транзакций.
К данному каналу-очереди подключаем SI-роутер, работающий на заголовках сообщений.
Новое для flow сообщение не имеет технического заголовка PartnerComponent, поэтому по-умолчанию будет обрабатываться компонентой someComponentOne, обязанностью которой является указание в заголовке сообщения PartnerComponent следующей компоненты и отправка сообщения во внутреннюю очередь. Роутер вновь забирает сообщение из внутренней очереди и отправляет его на обработку в указанную компоненту.
Описание компонент, в которые отправляются сообщения из роутера.
Адаптер для отправки в выходную очередь.
Сборка (pom.xml)
Старый добрый Maven. Стандартная сборка от Spring Boot. Зависимости от SI и AMQP предоставляют все необходимые библиотеки. Также подключаем spring-boot-starter-test для реализации проверочных кейсов на JUnit.
Работа SomeComponent*.java
Транзакционные бины, подключенные как service-activator к flow SI. Вызов REST через RestTemplate и отправка во внутреннюю очередь через innerChannel. Достаточно, чтобы продемонстрировать работу с сервисом и удобно за-mock-ить в тестах.
Тестируем
В тесте testHappyPath мы проверили работоспособность flow, когда нет сбоев при вызове REST. Mock-аем все вызовы REST-сервисов без сбоев, бросаем сообщение во входную очередь, ждем в выходной, проверяем прохождение всех компонент по контенту тела полученного сообщения.
В тесте testGuaranteedDelivery мы проверили гарантированную доставку при сбое в одном из REST. Эмулируем однократный сбой при вызове сервиса из третьей компоненты, ждём доставку сообщения до выходной очереди, проверяем тело полученного сообщения.
Заключение
Мы сделали приложение с гарантированной доставкой. Остался ряд мелких нерешенных вопросов: повторная отправка сообщений происходит бесконечно и неуправляемо, кто поддерживает данное решение — администратор или эту поддержку можно автоматизировать? Мы решаем данные вопросы при помощи самописных приложений и индивидуальных настроек для каждого типа сообщения. Возможно, в будущем мы опишем эти решения.
Основы надежной передачи данных
Тем, кто стремится разобраться в сетях и протоколах, посвящается.
Протокол транспортного уровня
Обеспечивает логическое соединение между прикладными процессами, выполняющимися на разных хостах. Логическое соединение с точки зрения приложений выглядит как канал, непосредственно соединяющий процессы.
Протоколы транспортного уровня поддерживаются конечными системами, но не сетевыми маршрутизаторами (кроме — DPI). На стороне отправителя транспортный уровень преобразует данные прикладного уровня, которые получает от передающего прикладного процесса, в пакеты транспортного уровня, называемые сегментами.
Это делается разбиением (при необходимости) сообщений прикладного уровня на фрагменты и добавлением к каждому из них заголовка транспортного уровня.
Далее транспортный уровень передает сегмент сетевому уровню отправителя, где сегмент инкапсулируется в пакет сетевого уровня (дейтаграмму) и отсылается. На принимающей стороне сетевой уровень извлекает сегмент транспортного уровня из дейтаграммы и передает его вверх транспортному уровню. Далее транспортный уровень обрабатывает полученный сегмент таким образом, чтобы его данные стали доступны приложению-получателю.
Принципы надежной передачи данных
Надежная передача данных по совершенно надежному каналу
Простейший случай. Отправляющая сторона просто принимает данные от верхнего уровня, создает содержащий их пакет и отправляет его в канал.
Надежная передача данных по каналу с возможными ошибками
Следующим этап — это предположение, что все переданные пакеты получены в том порядке, в котором они были отправлены, но биты в них могут быть повреждены, в связи с тем, что канал иногда передает данные с искажениями.
В таком случае применяются механизмы:
Протоколы надежной передачи данных, обладающие подобными механизмами многократного повторения передачи, называются протоколами с автоматическим запросом повторной передачи (Automatic Repeat reQuest, ARQ).
Дополнительно, стоит предусмотреть возможность ошибок и в квитанциях, когда принимающая сторона не получит никакой информации о результатах передачи последнего пакета.
Решение этой задачи, используемое в том числе в TCP, состоит в добавлении в пакет данных нового поля, содержащего порядковый номер пакета.
Надежная передача данных по ненадежному каналу, допускающему искажение и потерю пакетов
Одновременно с искажениями, к сожалению, в сети присутствует потеря пакетов.
И для решения этой задачи требуются механизмы:
Дополнительно, кроме потери пакета, необходимо предусмотреть возможность потери квитанции или, если ничего не потеряно, ее доставки со значительной задержкой. Во всех случаях производится одно и то же: повторная передача пакета. Для контролирования времени в данном механизме используется таймер отсчета, который позволяет определить окончание интервала ожидания. Так в пакете net параметр TCPKeepAlive установлен на 15 секунд по умолчанию:
Передающей стороне необходимо запускать таймер каждый раз при передаче пакета (как при первой, так и при повторной), обрабатывать прерывания от таймера и останавливать его.
Итак, мы ознакомились с ключевыми понятиями протоколов надежной передачи данных:
Протокол надежной передачи данных с конвейеризацией
Применение конвейеризации приводит к:
Диапазон порядковых номеров и требования к размерам буферов зависят от действий, предпринимаемых протоколом в ответ на искажение, потерю и задержку пакета. В случае конвейеризации существуют два метода исправления ошибок:
Возвращение на N пакетов назад — протокол скользящего окна
Отправитель должен поддерживать три типа событий:
Выборочное повторение
Когда размер окна и произведение пропускной способности на задержку распространения велики, в конвейере может находиться большое количество пакетов. В таком случае ошибка отдельного пакета может вызвать повторную передачу большого количества пакетов, большинство из которых не требовались.
Пример
Лучшие теоритические практики собраны в практической реализации TCP. А если кто-то знает, как лучше — welcome.
Гарантированная доставка данных в tcp осуществляется за счет
Формат сообщений UDP
Протокол TCP предоставляет транспортные услуги, отличающиеся от услуг UDP. Вместо ненадежной доставки датаграмм без установления соединений, он обеспечивает гарантированную доставку с установлением соединений между прикладными процессами в виде байтовых потоков.
В протоколе TCP-соединения устанавливаются с помощью «тройного рукопожатия». Чтобы установить соединение, одна сторона (например, сервер) пассивно ожидает входящего соединения, выполняя примитивы LISTEN и ACCEPT, либо указывая конкретный источник, либо не указывая его.
Другая сторона (например, клиент) выполняет примитив CONNECT, указывая IP-адрес и порт, с которым он хочет установить соединение, максимальный размер TCP-сегмента и, по желанию, некоторые данные пользователя (например, пароль). Примитив CONNECT посылает TCP-сегмент с установленным битом SYN и сброшенным битом АСК и ждет ответа.
Когда этот сегмент прибывает в пункт назначения, TCP-сущность проверяет, выполнил ли какой-нибудь процесс примитив LISTEN, указав в качестве параметра тот же порт, который содержится в поле Порт получателя. Если такого процесса нет, она отвечает отправкой сегмента с установленным битом RST для отказа от соединения.
Если какой-либо процесс прослушивает какой-либо порт, то входящий ТСР-сегмент передается этому процессу. Последний может принять соединение или отказаться от него. Если процесс принимает соединение, он отсылает в ответ подтверждение. Последовательность TCP-сегментов, посылаемых в нормальном случае, (рис. а) Обратите внимание на то, что сегмент с установленным битом SYN занимает 1 байт пространства порядковых номеров, что позволяет избежать неоднозначности в их подтверждениях.
Гарантированная доставка данных в tcp осуществляется за счет
Функции транспортного уровня:
Средства сетевого уровня обеспечивают доставку данных между устройствами в составной сети (компьютерами, маршрутизаторами и т.д). Однако не следует забывать, что на одном узле может функционировать параллельно несколько программ, которым требуется доступ к сети. Следовательно, данные внутри компьютерной системы должны распределяться между программами. Поэтому, при передаче данных по сети недостаточно просто адресовать конкретный узел. Необходимо также идентифицировать программу-получателя, что невозможно осуществить средствами сетевого уровня.
Другой серьезной проблемой протоколов сетевого уровня является отсутствие средств, позволяющих передавать большие массивы данных. Когда исходные данные превышают максимально допустимый размер пакета сетевого уровня, то эти данные должны быть разбиты на порции, каждая из которых передается в сеть отдельным пакетом. Однако каждый пакет сетевого уровня передается по сети как единый, независимый от других блок данных. В случае если какие-либо пакеты «потерялись», то модуль сетевого протокола на принимающей стороне не сможет обнаружить потерю, и, следовательно, – обнаружить нарушение целостности общего массива данных. Поэтому средства транспортного уровня обеспечивают отсутствие потерь информации. Такой режим передачи данных получил название гарантированной доставки.
Таким образом, средства транспортного уровня представляют собой функциональную надстройку над сетевым уровнем и решают две основных задачи:
В настоящее время в Интернет используются два транспортных протокола – UDP, обеспечивающий негарантированную доставку данных между программами, и TCP, обеспечивающий гарантированную доставку с установлением виртуального соединения.
Доставка данных между приложениями
Для идентификации программ протоколы транспортного уровня в сети Интернет (TCP и UDP), используют уникальные числовые значения, так называемые номера портов. Номера портов назначаются программам в соответствии с ее функциональным назначением на основе определенных стандартов. Для каждого протокола существуют стандартные списки соответствия номеров портов и программ. Так, например, программное обеспечение WWW, работающее через транспортный протокол TCP, использует TCP-порт 80, модули протокола FTP – TCP-порт 21, а служба DNS взаимодействует с транспортными протоколами TCP и UDP через TCP-порт 53 и UDP-порт 53 соответственно.
Таким образом, протокол сетевого уровня IP и транспортные протоколы TCP и UDP реализуют двухуровневую схему адресации: номера TCP- и UDP-портов позволяют однозначно идентифицировать программу в рамках узла, однозначно определяемого IP-адресом. Следовательно, комбинация IP-адреса и номера порта позволяет однозначно идентифицировать программу в сети Интернет. Такой комбинированный адрес называется сокетом (socket).
Принцип гарантированной доставки основан на том, что передающий компьютер всегда «знает», была ли доставлены данные получателю или нет. Это обеспечивается тем, что принимающий компьютер подтверждает успешный прием данных. Если передающий компьютер не получает подтверждения, он пытается произвести повторную передачу. Режим передачи с гарантией доставки имеет существенный недостаток – сеть дополнительно загружается пакетами-подтверждениями. Это может оказаться принципиальной проблемой на каналах с низкой производительностью. Поэтому при широковещательной рассылке, а также для передачи небольших порций данных, если нет необходимости в подтверждении, используется режим передачи с негарантированной доставкой.
Очевидно, что использование подтверждений не является достаточным для обеспечения правильной передачи больших массивов данных. В результате возможных задержек и/или потерь с последующей повторной передачей, фрагменты массива данных могут быть доставлены в неправильном порядке, часть из них может оказаться продублированной. Для того, чтобы восстановить правильную последовательность данных, принимающей стороне необходимо выделить определенные ресурсы (например, память) и согласовать параметры передачи с отправителем. Следовательно, перед началом передачи абоненты должны обменяться некоторой служебной информацией и перейти в состояние готовности к взаимодействию. Такой режим передачи данных по сети называется передачей с установлением виртуального соединения. По окончании взаимодействия выделенные ресурсы, как правило, освобождаются и абоненты «выходят из состояния готовности», то есть соединение закрывается.
Протокол UDP (User Datagram Protocol) – протокол транспортного уровня, входящий в стек протоколов TCP/IP, обеспечивающий негарантированную доставку данных без установления виртуального соединения.
Поскольку на протокол не возлагается задач по обеспечению гарантированной доставки, а лишь требуется обеспечивать связь между различными программами, то структура заголовка дейтаграммы UDP (так называется пакет протокола) выглядит достаточно просто – она включает в себя всего четыре поля. Первые два поля содержат номера UDP-портов программы-отправителя и программы-получателя. Два остальных поля в структуре заголовка дейтаграммы предназначены для управления обработкой – это общая длина дейтаграммы и контрольная сумма заголовка.
Протокол TCP (Transmission Control Protocol) является транспортным протоколом стека протоколов TCP/IP, обеспечивающим гарантированную доставку данных с установлением виртуального соединения.
Протокол предоставляет программам, использующим его, возможность передачи непрерывного потока данных. Данные, подлежащие отправке в сеть, разбиваются на порции, каждая из которых снабжается служебной информацией, то есть формируются пакеты данных. В терминологии TCP пакет называется сегментом.
В соответствии с функциональным назначением протокола структура TCP-сегмента предполагает наличие следующих информационных полей:
Реализация режима гарантированной доставки
Для того, чтобы данные могли быть правильно собраны получателем в нужном порядке, в заголовке TCP-сегмента присутствует информация, определяющая положение вложенных данных в общем потоке. Отправляя подтверждение, получатель указывает положение данных, которые он ожидает получить в следующем сегменте, тем самым косвенно сообщая отправителю, какой фрагмент общего потока был успешно принят. Соответствующие поля заголовка TCP-сегмента получили название номер последовательности и номер подтверждения.
Перед началом передачи потока данных абоненты должны согласовать параметры передачи: размер окна и начальные номера последовательностей, относительно которых будет отсчитываться положение передаваемых в сегментах данных внутри общего потока. Очевидно, что такое согласование предполагает обмен специальными сегментами и выделение ресурсов, в частности, блоков памяти, необходимых для приема и обработки данных и подтверждений. Соответствующая последовательность действий называется установлением виртуального соединения.