Пользовательский заголовок IP / UDP / RTP в Windows XP (и выше) + общие вопросы сети - PullRequest
0 голосов
/ 22 января 2011

Множество вопросов, извините!

Я работаю с приложением для голосового чата (VoIP), и я думал о создании собственной реализации заголовков IP и UDP, а также небольшой дополнительной информации, в основном, seqчисло.Звучит очень похоже на RTP, но в основном меня интересует только номер seq или временная метка, и попытка реализовать весь мой собственный RTP звучит как кошмар со всей сложностью и данными, которые я вряд ли буду использовать.

Целевая ОС для приложения - Windows XP и выше.Я прочитал http://msdn.microsoft.com/en-us/library/ms740548%28v=vs.85%29.aspx на тему необработанных сокетов в Windows, и теперь я просто хочу получить подтверждение.У меня также есть несколько общих сетевых вопросов.

Вот следующие вопросы:

1) Согласно MSDN, вы не можете отправлять пользовательские IP-пакеты с источника, которого нет в списке сети.Я понимаю это из соображений безопасности, но есть ли способ обойти это?Моя идея состояла в том, чтобы, например, два клиента открывали связь UDP с сервером, не защищенным NAT, а затем заставляли клиентов подделывать заголовок источника, чтобы он выглядел так, как будто пакеты приходят с сервера, а не друг от друга, что устраняет необходимостьсервер как ретранслятор данных, чтобы пройти через NAT, который улучшил бы задержку.Я слышал о winpcap, но я не хочу, чтобы каждый клиент устанавливал какие-либо сторонние приложения.Учитывая количество DoS-атак, безусловно, должен быть какой-то способ обойти это, например, подделка сетевой таблицы, которую ОС использует для проверки подлинности заголовка источника?Будет ли это запускать антивирусные системы?Я чувствую, что было бы действительно интересно поиграть с IP-заголовками и выше, вместо того, чтобы просто использовать предопределенные заголовки.

2) У меня были проблемы со свободными библиотеками RTP, такими как JRTPLIB (что, вероятно, очень хорошо в любом случаепросто не хочу работать на меня) чтобы заставить их работать, больше, чем я мог почти терпеть, и я думаю просто написать свою собственную интерпретацию поверх UDP.Протоколы уровня приложений, такие как RTP, просто создают свой заголовок непосредственно внутри полезной нагрузки UDP с последующими фактическими данными?Я подозреваю, что это с учетом процесса инкапсуляции, но просто хочу убедиться.Если это так, не нужно создавать сокет RAW для реализации протокола уровня приложения, просто обычный сокет UDP, а затем ваша собственная интерпретация полезной нагрузки, приведенная выше?

3) RTP не дает никакого повышения производительности по сравнению с UDPтак как он добавляет больше заголовков, все, что он делает, это проверяет, что пакеты поступают в некотором роде правильным образом на основе временных меток и порядковых номеров, верно?Действительно ли полезно использовать реализацию RTP для базовых потребностей VoIP-проекта вместо того, чтобы добавлять базовую последовательность самостоятельно?Я понимаю, что для видеоконференцсвязи, возможно, вы на самом деле не хотите, чтобы кадры воспроизводились не по порядку, но в аудио-разговорах вы бы это заметили?

4) Если мое решение в # 1 неприменимо, и я быпридется использовать сервер в качестве ретранслятора данных между клиентами, будет ли многоадресная рассылка хорошим решением для снижения нагрузки на сервер?Поддерживается ли многоадресная рассылка в оборудовании для маршрутизации?

5) Это относится к вопросу 1).Почему маршрутизаторы / брандмауэры допускают такие вещи, как пробивание UDP-дырок?Например, два клиента сначала подключаются к серверу, затем сервер передает клиентский порт / IP-адрес другим клиентам, чтобы клиенты могли общаться друг с другом через эти порты.Почему брандмауэры позволяют получать данные с другого IP-адреса, отличного от того, который использовался при подключении к этому порту?Похоже на большую дыру в безопасности, которую нужно легко отфильтровать?Я понимаю, что подмена IP-адреса источника обманула бы его, но это?

6) Чтобы настроить сеанс UDP между двумя сторонами (клиент, который находится за NAT, сервер, который не является NAT), клиент просто имеетотправить пакет на сервер и после этого сеанс разрешен через брандмауэр?То есть клиент тоже может получать с сервера.Основано на статье в вики, http://en.wikipedia.org/wiki/UDP_hole_punching

7) Зависит ли SIP от RTP?По какой-то причине у меня сложилось такое впечатление, но я не могу найти данные для его подтверждения.Я могу планировать добавить функциональность софтфона в мой VoIP-клиент в будущем и хочу убедиться, что у меня есть хорошая основа (RTP, если мне действительно нужно, иначе моя собственная интерпретация UDP)

Заранее спасибо!

1 Ответ

1 голос
/ 23 января 2011

1, необработанные сокеты кажутся ненужными для этого приложения

2, Да

3, RTP работает поверх UDP, конечно, это добавляет накладные расходы.Во многих отношениях RTP (игнорирование RTCP) уже в значительной степени является минимальным, и если вы внедрили половинную достойную альтернативу, это сэкономит вам в лучшем случае несколько байт, и вы не сможете использовать ни один из многих инструментов тестирования RTP..

7, SIP полностью независим от RTP.SIP используется для инициации сеансов.SDP - это протокол, который обычно передается по протоколу SIP, и это SDP , который согласовывает и контролирует видео / голос RTP.

...