UDP paket server

[eiffel]

Mám následující problém:
Posílám audio streamy ze studia na vysílače. Jelikož je studio na NATem, mají kodeky na vysílačích pevné IP adresy a pouze naslouchají na daném portu. Streamovací kodek za NATem ve studiu posílá stream na tyto konkrétní pevné IPky a vše je v pohodě. Bohužel jsou místa vysílačů, kde pevná adresa není možná.

Varianta 1 - provizorní, ale chodivá - sw icecast na vnějším serveru s pevnou IP, který přijme stream a "vystaví" ho, a kodeky si aktivně "chodí" na tuto pevnou IP pro stream. Problém- latence.

Varianta 2 - "něco", co na pevné IP poslouchá na daném portu pakety  a "vystaví" je pro případné zájemce. Jelikož HW je kompatibilní, odpadá nutnost stream dekódovat a znova skládat jako ve var. 1. a vše mohu udělat na úrovni UDP paketů.

Ještě než sednu ke kompilátoru C a napíšu si to sám, nenapadá někoho - zda toto neudělal někdo přede mnou ?  ( je to jako propojit dvě zásuvky... což není moc typické)

[Reklama]

[Petr Krčmář]

Zkus nástroje socat nebo netcat.

[eiffel]

Dík za tip, nicméně - pokud špatně nečtu -  oba nástroje neumí být server na dvou portech a posílat data z jednoho na druhý... select a spol. to asi jistí... ;-)

[Filip Jirsák]

Pokud by ten přeposílač měl pakety buferovat a na požádání je začít posílat vysílači, musí ten vysílač umět nějak o zasílání požádat – asi poslat na ten přeposílač nějaký paket, který to odstartuje. Tím odstartováním se zároveň udělá „díra“ do NATu u toho vysílače, aby NAT věděl, kam ty pakety posílat. Jenže to je vlastně to jediné, co potřebujete. Takže ten přeposílač by asi nemusel na obou stranách poslouchat, mohl by ty pakety pouze tupě přeposílat na veřejnou IP adresu NATu před tím vysílačem. Pak stačí, aby vysílač poslal správný UDP paket směrem k tomu přeposílači (který ten paket klidně může zahodit), tím si otevře dveře v NATu a začnou k němu proudit ty pakety posílané přeposílačem.

A nebo ty UDP pakety vůbec nemusíte posílat přes ten přeposílač, můžete si takhle otevřít průchod NATem na obou stranách a server s veřejnou IP adresou použít jenom k domluvě studia a vysílače na tom, jaké IP adresy mají použít. Takhle fungují různé protokoly, které umí peer-to-peer komunikaci mezi zařízeními, která jsou na obou stranách za NATem.

Hlavně, že pořád někdo tvrdí, že IPv6 vůbec není potřeba…

[dzavy]

To trivialne nejde, neexistuje zadny "vystaví", UDP je nestavovy a nespojovy, takze to proste musi neco posilat tak jako tak primo klientovi.

Resenim by byl nejaky tunel iniciovany ze strany klienta/vysilace.

[Reklama]

[Roman Šafránek]

Jestli je možnost mít prostředníka, pak bych udělal VPNky. Latence minimální, bude to bezpečné, není potřeba měnit stávající způsob distribuce a navíc bude přístup třeba i ke správě těch vzdálených lokalit

[František Ryšánek]

Jestli je možnost mít prostředníka, pak bych udělal VPNky. Latence minimální, bude to bezpečné, není potřeba měnit stávající způsob distribuce a navíc bude přístup třeba i ke správě těch vzdálených lokalit

A pokud se jedná o streaming, tak na rozdíl od holého UDP, kde opačným směrem nemusí téct *nic*, pokud bude použita VPN jako mezivrstva, tak ta mezivrstva si občas pošle opačným směrem aspoň nějaký keepalive, pokud ne rovnou TCP ACK = udrží v NATu otevřenou stateful session. Možná byste skrz tu VPN protlačil i multicast. Pokud by to utáhla OpenVPN, tak stojí za zvážení/otestování udělat tu hvězdu s enkapsulací "TAP" = celé eth. rámce a multi-exit síť (na satelitních lokalitách mezi LAN a VPN raději routovat). Otázka je, jak to celé bude reagovat na výpadky paketů = nakolik je výpadek paketu problém a statisticky jak často k němu na použitých trasách dochází...

[Ladislav Zitka]

OpenVPN podporuje UDP pro nizsi latence.

[stevo54785]

Icecast má možnosť nastaviť bufery - s tým úzko súvisí latencia. Je tu tiež možnosť relay v icecaste. Myslím, že to je to čo hľadáte http://www.icecast.org/docs/icecast-2.4.1/config-file.html#relay

[eiffel]

Věc má (tedy spíše měla) háček. Pro přenos modulace se používá jednoúčelový HW, který přílišnými možnostmi neoplývá. VPN bez dalšího HW nepřipadá v úvahu, nehledě na to, že každý "tunel" je trnem v oku všem paranoidním IT bezpečákům. 
Relay za pomoci Icecastu je nemožné, protože HW neumí vyslat Icecastu autentizaci.
Takže jsou dvě řešení : Řešení 1 - kodek ve studiu za NATem pošle na pevnou IPku rtp stream, který chytnu VLCčkem, které zároveň donutím transkodovat na mp3 stream pro icecast, který jej "sežere" na stejném stroji a vystaví ho jako html stream ven. Kodeky na vysílačích si pro něho "chodí", jako třeba na play.cz.  Toto řešení chodilo asi za půl hodiny. Snažil jsem se donutit VLC k html streamu čímž by odlpadl Icecast, ale marně. (pozn - pod windows to chodilo bez problémů)
Řešení 2 - v podstatě to samé, jen jsem si to celé napsal sám. Rpi 3+ se tomu směje...
Každopádně děkuji za reakce.

[František Ryšánek]

Gratuluji k vlastnoručnímu řešení a k pečlivé práci.
A děkuji za sondu do zákulisí, "jak se to dneska dělá".
Už si nebudu tolik lámat hlavu, proč některým rádiím tady "na severu" slyšitelně skáče buffer dopředu a zpátky, inteligentně o celé slabiky v mluveném slově nebo o čtvrt taktu v hudbě - to není výtka vůči Vašemu řešení, v rámci rozpočtu jste nejspíš udělal víc než bylo možné.
Přeji Vaší konektivitě nulové ztráty paketů. (Ztráty paketů a případné TCP retransmise nejsou jediný faktor, ono to může souviset taky s kvalitou hodin ve "studiu" a na vysílačích, což je další záležitost, která není levná.)