Отладка потери пакетов в TCP-связи в приложении iOS/iPad

Question

У меня есть приложение iOS, которое дистанционно соединяется с 3 сокетами (определенного оборудования). У каждого сокета есть свой приоритет. Один канал используется только для передачи сообщений между iPad App &, один для изображений Tx/Rx, другой для видео Tx/Rx. Я реализовал все три сокета, используя GCDAsyncSocket API & все работает нормально при использовании MSGSocket/ImageSocket (OR) MSGSocket/VideoSocket, но когда я начинаю использовать VideoSocket/ImageSocket/MSGSocket одновременно, это происходит там, где все идет немного. Я теряю пакеты данных. {Фактически отсутствует фрагмент файла :-(} Я прошел через API & нашел ошибку в API: Unable to complete Read Stream, которая, как я полагала, может быть причиной проблемы. Следовательно, я переключился на потоки & реализован тот же с помощью NSThreads/CFSocket API.

Я изменил только реализации для ImageSocket/VideoSocket кода с использованием NSThreads/CFSocket API & здесь реализация того же dropbox-ed. Я просто не в состоянии понять, как туда, где все идет не так, независимо от того, находится ли это в приложении iOS или на стороне сервера. По моему мнению, в TCP Communication не будет потери пакетов.

Есть ли способ отладки этой проблемы. Также я прошу пройти код &, сообщите мне, если что-то не так (я знаю, что это может быть слишком много, о чем я прошу, но мне нужна уверенность в правильности реализации кода). Любая помощь для решения этой проблемы будет высоко оценена.

EDIT 1: После @JoeMcMahon комментарий, я назвал это Technical Q&A & получил TCP Dump - trace.pcap file. Я открыл этот дамп tcp с Wireshark &, он показывает мне байты, переданные между портами аппаратного обеспечения & iPad. Кроме того, в терминале, когда я остановил захват TCP дамп Я видел эти сообщения:
12463 пакеты захваченные
36469 пакеты, полученные фильтром
0 пакетов, отброшенных ядром
Может кто-то указать на различие между пакетами захватили & пакеты, полученные по фильтру?
Примечание - Сброс TCP-дампа не относится к неудачному сценарию.
РЕДАКТИРОВАТЬ 1.1: Найдено ответ на разницу между пакетами захваченных & пакетов, полученных с помощью фильтра here

Answer 1

TCP связь не гарантирована, чтобы быть надежными. Базовая парадигма ack-syn может сломаться, поэтому у вас есть механизм ретрансляции и т. Д. Wireshark сообщает о такой проблеме в сеансе захвата пакетов.

Для использования wirehark/tcpdump вы обычно хотите предоставить фильтр, так как количество трафика, проходящего через провод, является подавляющим (ping, ntp и т. Д.), Вы хотите отфильтровать захват с помощью некоторого базового фильтра, чтобы увидеть пакеты, которые относятся к вам. Пакеты, которые отфильтровываются, не фиксируются, следовательно, численная разница.

Если это фрагмент файла пропал, я сомневаюсь, что проблема на уровне TCP. Скорее всего, это что-то более высокий уровень пошло не так. Я буду запускать файл фиксированного размера повторно через канал, чтобы я мог достоверно воспроизвести потерю.