Выбор протокола?

Question

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

Answer 1

Я разработал игры, в том числе те, которые классифицируются как «дерганные» игры, такие как гонки и FPS. Для этого типа игры очень важна задержка. Вы не можете использовать TCP, потому что он гарантирует доставку в порядке и будет удерживать входящие пакеты, пока выполняется повторная отправка.

То, что мы сделали для большинства из них, - это использование того, что мы называли Stateful UDP. Все, что на самом деле означает, - это то, что мы добавили в сообщение идентификатор пакета. Когда мы получили сообщение, мы проверили ID. Если идентификатор был выше, чем самый высокий идентификатор, который мы видели далеко, мы приняли и обработали этот пакет. Если оно было ниже, мы его уронили. Этот подход хорошо работает, когда важна задержка, так как даже с UDP вы получите большинство ваших пакетов, и большинство будет в порядке.

Answer 2

Потоковое видео и аудио не так просто. Вы должны посмотреть на то, что уже существует - RTP , чтобы узнать, что вы пытаетесь изобрести заново; -)

Answer 3

TCP не подходит для такого рода приложений. Проблема с ретрансляцией. Если получатель решает, что пакет потерян или поврежден, и запрашивает повторную передачу, TCP не разрешает повторную передачу одного пакета. Каждый пакет из потерянного / поврежденного пакета передается повторно. С постоянным потоком пакетов с высокой пропускной способностью, проходящим через сеть, один маленький сбой вызовет недопустимые задержки в видеопотоке, которые вы, возможно, не сможете восстановить.

Используйте UDP в качестве транспорта и разработайте прикладной уровень таким образом, чтобы вы могли изящно ухудшать работу при ухудшении состояния сети.

Answer 4

Следует обратить внимание на то, что при использовании TCP (при условии некоторого кодирования MPEG), если пакеты задерживаются из-за проблем с сетью, видео будет зависать или задерживаться до тех пор, пока не поступят данные. Видео, по определению TCP, будет безошибочным.

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

Если то, на что указывает камера, движется и пропадание дельта-кадров может действительно испортить изображение, тогда может потребоваться протокол TCP, чтобы гарантировать, что, если вы получаете видео, оно, по крайней мере, точно. Однако, если вы указываете на что-то довольно стационарное (что, вероятно, не так, если это для видеоконференций), тогда может быть достаточно UDP, поскольку случайная потеря дельта-кадра, вероятно, не повлияет на общее качество видео.

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