как правильно осуществить передачу аудио между двумя клиентами?

Question

[vvsh]

правильный ли способ передачи аудио между клиентами:

1) первый клиент делает запрос на сервер по протоколу tcp
2) сервер проверяет доступен ли второй клиент:
a) посылает второму клиенту запрос на подтверждение вызова и адрес (InetAddress) первого клиента
b) второй клиент его подтверждает и посылает подтверждение серверу
c) сервер посылает первому клиенту адрес (InetAddress) второго клиента.
3) клиент начинает передачу пакетов (DatagramPacket) через DatagramSocket напрямую второму клиенту

вот в 3 пункте возникает вопрос: правильно ли передавать пакеты напрямую или лучше сделать промежуточный сервер?
спасибо

Answer 1

[vvsh]

наверное проще с tcp сделать, я попробовал но получается большая задержка…

Answer 2

[barker]

Вышеотписавшимся в том числе: никакого tcp при передаче аудио/видео быть не должно! Если имеется ввиду именно реалтайм передача/трансляция, конечно. По очевидным причинам нужно только udp использовать.

Comments

[vvsh]

можете объяснить почему обязательно udp.
просто при передачи через tcp нет потери пакетов, и качество очень хорошее, никаких прерываний.

[vvsh]

и можно ли сжимать данные перед передачей с помощью класса Deflater?

[barker]

При tcp будут гарантированные растущие лаги. Разве это не очевидно? Будет постоянно расти отставание частей от временных меток в которые они должны пройти. Для передачи реалтайм потока такого вида важнее именно реалтаймовость, нежели пропадение пакетов. А если у вас видео/звук уже отстаёт, вам просроченные пакеты совершенно не нужны, если вдруг пришли новые, более поздние. «Качество» определяется сжатием больше. Или про что вы? У вас что, так сильно теряются пакеты, что прерывается звук? Такого быть не должно.

Не очень понял про класс, но если сжимается именно отдельный пакет, то можно. Если сжимается весь поток так, что без некоторых пакетов разжать его нельзя, то… нельзя.

[barker]

Отставание будет расти, т.к. пакеты постепенно теряются. И в тот момент, когда пришла пора использовать новую информацию (у вас же реалтайм) — идут попытки получить прошлый пакет. В случае udp у вас этот новый пакет уже как бы есть. Это грубо говоря.

[barker]

Блин, поспешил. Сообщение выше — это я про tcp.

[vvsh]

да понятно, что будет задержка, но с udp есть проблемы.
во-первых с tcp я мог сжимать информацию и потом обратно распаковать, так как уверен что не будет потерь.
во-вторых с tcp можно установить постоянное соединение.

может подскажите, как можно установить соединение между двумя клиентами через udp сервер, как их подключить к нему?
спасибо

[ValdikSS]

samy.pl/pwnat/
en.wikipedia.org/wiki/UDP_hole_punching

Answer 3

[Evengard]

Проще сделать через промежуточный сервер если вы не хотите мучиться с NAT transversal-ом.

Comments

[vvsh]

а как правильно реализовать промежуточный север чтобы не было проблем с nat'ом?

[Evengard]

А собственно в чём проблема-то?
1. первый клиент подключается к промежуточному серверу
2. Второй клиент подключается к промежуточному серверу
3. Первый клиент передаёт байты (tcp или udp не так важно, с tcp наверное будет попроще немного, но ХЗ)
4. Сервер принимает данные и отправляет к подключившемуся второму клиенту.
Вроде всё.

[vvsh]

как раз с этим проблем нет
проблема сделать этот сервер многопоточным, так может быть много звонков одновременно.

[Evengard]

Попробуйте заюзать Netty. См тут: habrahabr.ru/post/136456/