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

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

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

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

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

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

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

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



P.S.

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

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

Это сообщение отредактировал(а) SVK - 10.12.2008, 21:11

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