UDP czy TCP do przesyłania dzwięku

Tworzę aplikacje która będzie przesyłać/odbierać dźwięk do/z serwera. Z tego co mi wiadomo używa się do tego protokołu UDP. Problem jest taki że aplikacja będzie się łączyła z różnych sieci na całym świecie. Pytanie czy przez UDP mogę to rozwiązać czy zostaje mi tylko TCP?

A czy UDP jest w jakimś kraju zakazane?

chyba nie do kończa rozumie działania MulticastSocket. To joinGroup to jest IP "servera" czy tak jakby kanał na ktorym nadaje diagramy i jest dostępny z każdej sieci na całym świecie? Czy tylko w danej podsieci?

Możesz skorzystać z protokołu UDP. Serwer musi być wystawiony publicznie (tzn. mieć publiczne ip ewentualnie proxy) aby komunikacja była możliwa z różnych sieci na całym świecie.

chyba nie do kończa rozumie działania MulticastSocket. To joinGroup to jest IP "servera" czy tak jakby kanał na ktorym nadaje diagramy i jest dostępny z każdej sieci na całym świecie? Czy tylko w danej podsieci?

Multicast to jest pewien szczególny rodzaj komunikacji. IP jest adresem grupy, nie serwera. Idea jest taka, że infrastruktura sieciowa zjamie sie dostarczeniem pakietów do wszystkich w danej grupie. W praktyce multicast nie jest routowany poza sieciami lokalnymi, więc raczej nie o to ci chodzi. Musisz napisać serwer który będzie rejestrowac zainteresowanych klientów i rozsyłać do każdego z osobna dane.

Do takich rozwiązań głównie używa się UDP. W UDP nie ma retransmisji pakietów które nie dotarły - bo na co Ci dane które są już mocno opóźnione.

Mimo wszystko UDP też ma swoje problemy - np. brak informacji zwrotnej czy pakiet dotarł oraz czy klient nie jest zalewany zbyt dużą ilością pakietów.

Dlatego np. w H.323 używa się i TCP i UDP.

Możesz popatrzyć jak są skonstruowane takie protokoły:
RTSP
H.323

W takim razie jak uzyc UDP tak aby serwer przyjmować kilka klientów i przyjmował i rozsyłał miedzy nimi pakiety. Musiałbym użyć DatagramSocket? Powiedzmy że chce zrobić aplikacje typu teamspeak

@volau: rzuć okiem na Netty i tyo jak tam można zrobić steaming.

UDP to protokół bezpołączeniowy więc musisz sam zadbać o wiedze po stronie serva, kto ciągle chce otrzymywać datagramy.
Np. Gdy klient prześle pierwszy datagram możesz wygenerować uuid go identyfikującego i mu odesłać aby kolejne datagramy wysyłał
z tym identyfikatorem. Musisz pamiętać, że datagramy powinny być "lekkie" w granicach 512-1024B.

Porozglądałem się po googlach, i w sumie nic konkretnego nie znalazłem. Zdecydowałem się użyć AsynchronousServerSocketChannel z timeoutem. Pytanie czy dobrze zrobiłem oraz jak wykryć koniec przysyłanych danych jak wiadomo duży pakiet danych na tcp może zostać poszatkowany na mniejsze. Doklejać wielkość na początku albo jakiś znak na końcu danych?