Данные не по порядку в TCP - PullRequest
Новая
       27

Данные не по порядку в TCP

0 голосов
/ 30 августа 2018

У меня есть приложение, использующее минимальную библиотеку Apache для связи на основе TCP. Мина-библиотека apache предоставляет функцию обратного вызова с IOBuffer, которая содержит данные, поступающие по сети, однако часто данные поступают не по порядку или с избыточностью. Я пролистал протокол TCP, и он говорит, что протокол всегда обеспечивает доставку данных в правильном порядке. Компания, предоставившая API-интерфейсы для своего сервера, заявляет, что они используют TCP / IP для отправки ответа обратно, однако перед отправкой ответа их сервер не заботится о том, чтобы подтвердить, является ли клиент (в данном случае моя библиотека application / apache mina) подключен к серверу. Таким образом, сервер просто отключает сообщение и продолжает работу.

Если я не ошибаюсь, это поведение протокола UDP. У меня вопрос, если сервер использует TCP для отправки ответа обратно:

  1. Почему я получаю данные о заказе (это редко, но случается время от времени)?
  2. Как может машина, использующая протокол TCP, просто запустить и забыть о данных, не убедившись, что приемное устройство подключено к ней перед отправкой данных?
  3. Это действительно TCP или UDP или какой-то вариант протокола TCP?

1 Ответ

0 голосов
/ 30 августа 2018

Apache Mina выполняет асинхронный обмен сообщениями поверх различных транспортов, включая TCP.

Поскольку Mina является асинхронной, следует ожидать доставки вне очереди.

Почему я получаю данные о заказе (это редко, но случается время от времени)?

Одним из возможных объяснений является использование нескольких потоков TCP. Данные, доставленные с использованием одного потока TCP, будут доставляться по порядку, но если используется несколько потоков, данные в одном потоке могут «обогнать» данные в другом потоке, в стеках TCP на передающей или принимающей стороне, в сети или в клиентская библиотека.

Как может машина, использующая протокол TCP, просто запустить и забыть о данных, не убедившись, что приемное устройство подключено к нему перед отправкой данных?

Потому что ... надежная доставка не является основным атрибутом Мины.

Если вы используете Mina для связи со службой с конкретным протоколом приложения, то этот протокол определит, будет ли разрешена / будет работать «отправка данных до проверки подключения получателя» или нет. Например, это не относится к ответу HTTP, поскольку ответ HTTP отправляется на соединение, которое было ранее установлено для отправки запроса.

На самом деле, кажется, что есть множество способов использовать Мину. Некоторые включают протокол приложения; например см HttpClientCodec и HttpServerCodec. Другие нет.

Это действительно TCP или UDP или какой-то вариант протокола TCP?

Если они говорят, что TCP используется в качестве транспорта, то это так. Однако Мина не является ни TCP, ни UDP. Это Мина. Это скрывает детали транспорта.

Итог: если вам нужны свойства надежности / порядка доставки TCP / IP, вам, вероятно, следует использовать их напрямую. Mina обеспечивает более высокую производительность, чем обычный TCP / IP, через синхронный сокет, ослабляя нормальные свойства (одного) потокового транспорта.

...