reklama

UDP paket server

UDP paket server
« kdy: 12. 04. 2019, 18:49:16 »
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é)
« Poslední změna: 12. 04. 2019, 18:56:36 od Petr Krčmář »

reklama


Re:UDP paket server
« Odpověď #1 kdy: 12. 04. 2019, 18:58:43 »
Zkus nástroje socat nebo netcat.

Re:UDP paket server
« Odpověď #2 kdy: 12. 04. 2019, 19:59:36 »
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í... ;-)

Re:UDP paket server
« Odpověď #3 kdy: 12. 04. 2019, 20:18:05 »
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…

Re:UDP paket server
« Odpověď #4 kdy: 15. 04. 2019, 15:53:46 »
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.


Re:UDP paket server
« Odpověď #5 kdy: 16. 04. 2019, 08:00:54 »
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

Re:UDP paket server
« Odpověď #6 kdy: 18. 04. 2019, 15:23:48 »
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í...

 

reklama