Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Java: Работа с сетью > UDP и локальные сети


Автор: SVK 9.12.2008, 05:17
Задача: пересылать звук с сервера в JAVA-аппликуху на клиенте.
Сделана пересылка пакетов по ТСР - все работает, но есть проблема с медленными сетями - либо недопустимо большая задержка, либо - пропадание пакетов, заикание. Заказчик не берет. Хотим перейти на UDP или RTP, но там другая проблема - локалки. 

Вопрос: можно ли каким-то образом по UDP послать данные с сервера на комп, который стоит в где-то в локалке, VPN-e и выходит "в свет" через гейт под IP гейтa? Например, сначала клиент соединяется с серваком по TCP, договаривается о портах, посылает ему что-то по UDP, а потом - принимает от сервака по UDP? Поймет ли гейт, кому пересылать датаграмму? Skype ведь делает как-то. Рылся рылся - не нашел про это. Проверить тоже не могу - локалки под рукой нет.

Автор: LSD 9.12.2008, 12:54
1. Skype использует UPnP для открытия портов и другие компьютеры сети когда порт нельзя открыть. Для UDP подходит только первый вариант, второй отпадает.

2. Как пересылка данных через UDP может улучшить ситуацию с медленными сетями? ИМХО вы не с того конца подходите к проблеме.

Автор: SVK 9.12.2008, 21:16
LSD, 1. Порты мы можем потребовать открыть ручками (дать инструкцию клиенту). UPnP, вроде, и не надо.

2. Поправлюсь - речь скорее не о медленных, а о загруженных сетях. TCP все доставляет надежно, но часто с задержкой в несколько секунд - пока все привет-ответы-повторы пройдут. Приходится сильно буферизиривать. А нам надо иметь аудио чат и задержка допустима в пределах 1-2, ну, 3-х секунд. При этом пропадание некоторых пакетов некритично - важно, чтобы речь была слышна гладко, без заиканий, которые сейчас имеют место быть из-за того, что какой-то пакет застрял. То есть, нужен быстрый, пусть и ненадежный транспорт. Для этого случая UDP - то, что доктор прописал (это не мое ИМХО, а общепринято - могу ссылок накидать). И RTP, специализирующийся на мультимедиа, не случайно поверх UDP сделали. И тот же скайп недаром использует UDP как основной, а TCP только тогда, когда UDP невозможен. 

Автор: LSD 10.12.2008, 15:32
Если не фигачить в сокет поток аудиоданных, а передавать их небольшими блоками и именно актуальные данные, то и TCP/IP подойдет.

Алгоритм приблизительно такой: есть поток который читает данные с аудиоустройства и кодирует их в  небольшие законченные блоки в 1-16 килобайт (размер подобрать экспериментально в зависимости от качества канала) и кладет данные в буфер на отправку. Есть поток который отсылает данные в сеть, он берет данные из буфера и проверяет их актуальность. Если данным более Х миллисекунд, то они уже не актуальны и просто выбрасываются из буфера без отправки их куда либо и так до тех пор пока не дойдет до актуальных данных. Если у нас возникла некий лаг и данные не передавались в течении минуты, то потом данные за последнюю минуту просто будут проигнорированы.



P.S.
Цитата(technet.microsoft.com)
The GSM audio codec creates .wav audio files that are compressed. GSM .wav audio files are just over 16,000 bytes for each 10 seconds of audio.

Какой же должен быть канал, чтобы не потянуть такой поток данных? Модем на 2400, что ли? smile 

Автор: SVK 10.12.2008, 21:08
LSD, спасибо за участие, но Америку для нас Вы, к сожалению, не открыли. У нас так и сделано - аудио поток рубится примерно по 0.7 сек, пропускаются через кодек - получается 1кб, пакет пересылается на сервер, другой клиент забирает свои пакеты, буферизирует, играет. Все работает, качество хорошее, но задержка - 2-7 сек. и эпизодические замирания (нечастые) заказчику не нравятся - некомфортно для чата. Мы же не музыку гоняем, а диалог. Причем в локалке задержка 1-2 сек, а когда сервер далеко - от 2x до 7-ми. Так что, более быстрый, чем TCP, транспорт - ЕДИНСТВЕННОЕ решение. Сегодня будем пробовать UDP хотя бы в одну сторону.

Автор: LSD 11.12.2008, 14:01
Ну если у вас задержка на пересылку 1 кб данных несколько секунд, то вам и UDP вряд ли поможет. 1 кб спокойно помещается в один пакет.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)