Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > 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.
Какой же должен быть канал, чтобы не потянуть такой поток данных? Модем на 2400, что ли? ![]() |
Автор: 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 кб спокойно помещается в один пакет. |