1

У меня есть приложение для потоковой передачи видео по UDP, и он полностью работает. Я заменил сокет на TCP. Когда он запускается после передачи нескольких пакетов, приемник отправляет RST и перестает работать. (Пакет с большой длиной также странно, который передается от отправителя к получателю, а MTU 1400 - что этот пакет?)RST В потоковой передаче видео через TCP-сокет?

enter image description here

Я проверил приемник и журнал отправителя. Последний пакет, полученный приемником, имеет большой и странный порядковый номер (пакет дампа). Он делает ошибку, а затем приложение останавливается. Отправитель не отправляет такой пакет. Откуда этот пакет? Это транспортный слой, который это делает?

enter image description here

Когда я добавил время сна (0,1 секунды) отправителю после того, как каждый пакет отправки. Программа работает без каких-либо странных пакетов большой длины в Wireshark или странном порядковом номере. Но это не разумное решение для видео. Какое ваше предложение сейчас? В чем может быть проблема? Как анализировать эту сеть? Как это можно решить?

+0

Что является причиной изменения типа сокета от TCP до UDP? – szulak

+0

от UDP до TCP. Я собираюсь изучить разницу, и позже я попытаюсь реализовать новый протокол на основе TCP. –

+0

Как правило, MTU на интерфейсе loopback (один с адресом 127.0.0.1) составляет 64 КБ на Linux (16 КБ на MAC - не уверен в Windows). Размер вашего буфера приложений напрямую не определяет объем данных, отправляемых в каждом TCP-пакете. ОС может вставлять столько данных в полезную нагрузку TCP, сколько доступно в момент, когда она решает отправить (с учетом MTU, окна получателя и т. Д.). Возможно, вы захотите изучить опцию «TCP_NODELAY» (см. 'Tcp (7)' man page). –

ответ

0

Это не странная длина. Это, вероятно, tcp разгрузка. См. ethtool -k interface. Выключите выгрузку и повторите попытку. Первое, вероятно, не связано. Вероятно, это проблема с приложением.

Смежные вопросы