UDP -protocol

Реализовал я TCP protocol который принимает 1 500 000 байт в 150 - 200 мс, а хотелось бы быстрее, по этому рассматриваю UDP протокол, говорят что он быстрее, по итогу udp отправляет 64k а TCP 64 - 100к, но в играх и при передачи видео используют udp протокол, и тут я задумался о многопоточности но не могу представить двойной recvfrom и двойной sendto (winsock), задумался о том чтобы подключать сразу 2 сокета с одного клиента (как будто бы 2 клиента), но сомневаюсь в правильной последовательности полученных сокетов, направьте в правильное русло

0

Сообщение от TonySem но сомневаюсь в правильной последовательности полученных сокетов, направьте в правильное русло

При работе с udp всегда будет проблема с последовательностью и потерей пакетов, даже на одном сокете.

0

TonySem, UDP работает в том же стеке, что и TCP, поэтому в общем случае он не быстрее. Он более гибок, и позволяет, например, игнорировать потерянные пакеты.

В обязанности TCP входит гарантированная доставка всех отправленных данных, причем в исходной последовательности, поэтому приемник довольно долго ждет заблудившиеся пакеты прежде, чем до него доходит, что ждать придется вечно. Потом он отправляет запрос передатчику на переотправку потеряшек, снова ждет, и т.д. И все это время блок данных, в который входят не доставленные пакеты лежит во внутреннем буфере системы и не отдается принимающей программе.

UDP относится к жизни пакетов намного проще: передатчик отправил пакет куда-то в сторону приемника и забыл о нем навсегда. Дойдут ли пакеты вообще, дойдут ли в порядке отправления, его не волнует, это теперь забота приемника. Зато любой прилетевший пакет сразу передается в лапы принимающей программы, мгновенно. Поэтому при использовании UDP нужно самому заботиться о контроле последовательности данных и о потерянных пакетах.

Именно из-за этого UDP любят использовать для передачи медиа. Тут можно добавить некоторую избыточность в данные, чтобы потери были не критичны. А если даже потери окажутся больше ожидаемого, ничего страшного все равно не случится. Ну заикнется звук, или проскочат квадратики на видео в течении доли секунды. Все. А поток будет лететь в реальном времени с задержками на уровне чистого пинга.

Так что подумайте крепко, нужен ли вам этот геморрой, ведь вы, скорее всего, передаете данные, которые не терпят потерь, а значит вся эта трахолюдия с повторными отправками и выстраиваниями принятых фрагментов в правильной последовательности ляжет на вас.

1

Может быть попробовать сжать данные перед отправкой?

0