Отладка потери пакетов в связи TCP в приложении iOS/iPad
У меня есть приложение для iOS, которое удаленно подключается к 3 сокетам (некоторого оборудования). Каждый сокет имеет свой приоритет. Один канал используется только для передачи сообщений между приложением iPad и оборудованием, один для изображений Tx/Rx, другой для видео Tx/Rx. Я реализовал все три сокета, используя GCDAsyncSocket API, и все отлично работало при использовании MSGSocket/ImageSocket (OR) MSGSocket/VideoSocket, но когда я начинаю использовать VideoSocket/ImageSocket/MSGSocket одновременно, это немного мешает. Я теряю пакеты данных.{На самом деле часть файла пропадает:-(} Я прошел через API и обнаружил некоторую ошибку в API: Невозможно завершить чтение потока, что, как я предполагал, могло стать причиной проблемы. Следовательно, я переключился в потоки и реализовал то же самое, используя NSThreads/CFSocket API.
Я изменил только реализацию кода ImageSocket/VideoSocket с помощью API-интерфейса NSThreads / CFSocket, и вот реализация того же Dropbox-ed. Я просто не могу понять, где все идет не так, будь то в конце iOS-приложения или на стороне сервера. В моем понимании не должно быть никакой потери пакетов в связи TCP.
Есть ли способ отладки этой проблемы. Также я прошу просмотреть код и сообщить мне, если что-то не так (я знаю, что это может быть слишком много, о чем я прошу, но мне нужна некоторая уверенность в правильности реализации кода). Любая помощь для решения этой проблемы будет высоко оценена.
РЕДАКТИРОВАТЬ 1: После @JoeMcMahon Comment, я сослался на этот технический Q&A и получил файл TCP Dump - trace.pcap. Я открыл этот дамп tcp с помощью Wireshark, и он показывает мне байты, переданные между портами оборудования и iPad. Также в терминале, когда я остановил захват дампа tcp, я увидел эти сообщения:
12463 пакетов перехвачено
36469 пакетов, полученных фильтром
0 пакетов отброшено ядром
Может ли кто-нибудь указать на разницу между захваченными пакетами и пакетами, полученными фильтром?
Примечание. Подключенный дамп TCP не предназначен для сценария сбоя.
РЕДАКТИРОВАТЬ 1.1: Здесь нашли ответ на разницу между перехваченными пакетами и пакетами, полученными фильтром
1 ответ
TCP-связь не гарантируется как надежная. Базовая парадигма ack-syn может сломаться, поэтому у вас есть механизм повторной передачи и т. Д. Wireshark сообщает о такой проблеме в сеансе захвата пакетов.
Для использования wireshark/tcpdump вы, как правило, хотите предоставить фильтр, поскольку объем трафика, проходящего через канал, огромен (ping, ntp и т. Д.), Вы хотите отфильтровать перехват с помощью некоторого базового фильтра, чтобы увидеть соответствующие пакеты тебе. Отфильтрованные пакеты не перехвачены, отсюда и числовая разница.
Если это кусок файла пропал, я сомневаюсь, что проблема на уровне TCP. Скорее всего это что-то более высокого уровня пошло не так. Я неоднократно запускал файл фиксированного размера по каналу, пока не смогу надежно воспроизвести потерю.