TCP/UDP komunikace a NAT routery

[age.new]

Vážená komunito,

kdysi, v pubertálním věku, jsem se zajímal o programování "multiplayer" her. Narazil jsem ale na problém, který jsem tehdy nedokázal vyřešit. Měl jsem jednoduchý UDP server, který se staral o rozesílání dat všem připojeným hráčům. Komunikace v podstatě fungovala, podmínkou ale bylo přesměrování portů na straně klienta. Jeden kamarád se tak mohl připojit, protože dokázal nastavit svůj router. Další kamarádi to ale nedokázali. Když se podívám na většinu dnešních "multiplayer" her, tak není třeba NAT router nastavovat. Přesto hra využívá i více UDP portů (někdy i TCP). Tato logika přesměrování mi dodnes není úplně jasná. Domníval jsem se, že když klient zahájí UDP komunikaci jako první, NAT router pak povolí komunikaci v obou směrech na daném portu. Patrně to ale tak nefunguje.

Má zde někdo zkušenosti se Server-Klient komunikací mimo lokální síť? Jak se řeší obcházení NAT routerů bez nutnosti je interně nastavovat?

Děkuji.

[geby]

TCP i UDP fungují vždy na principu client-server. Client se pripojuje k serveru (i u UDP zpravidla client pošle serveru dotaz a čeká na odpověď)

NAT zase funguje tak, ze kdyz je client na lokalni siti a iniciuje spojeni ven k nejakem serveru, tak si to router na nejakou dobu zapamatuje, aby vedel, jakemu lokalnimu pocitaci ma odpoved serveru preposlat.

Takže řešení je prosté - všechno, k čemu se mají programy připojovat (posílat data, atd.), musí mít server přímo dostupný na inetrnetu. To jsou ty herní servery všemožných společností, ale třeba i webové servery, poštovní servery, atd.

Přesměrování portů pak potřebuješ jen tehdy, pokud bys chtěl nějaký takový server provozovat u sebe na lokální síti za NAT.

Podmínkou správného fungování je nemít zmatek ve zdrojových a cílovýh portech UDP komunikace. UDP musí od klienta vyrazit k serveru, a tím se na NAT otevře kanál klient_port <-> server_port. Server pak může zes právného portu zpět ke klientovi posílat odpovědi, třeba s tím stavem hry. A klient opačným směrem posílá na server svůj stav. To musí dělat tak často, aby se ta rezervace na NAT nezrušila pro nečinnost.

Takže když čtu tvuj popis fungování multiplayeru, tak si tipnu, že jsi ze serveru ke klientu neposila na port, ze ktereho se ti klient ozval, ale na nejaky pevne dany port. Proto bylo potreba nastavit presmerovani.  A to byla ta chyba - pevne dany port maji mit jen servery - uz i proto, že na jednom IP muze bezet jen jeden. kleinti pouzivaji zpravidla nahodne zvolene volne porty, a proto muze na jednom pocitaci bezet i vice kleintu vedle sebe, aniz by se pohadali.

[age.new]

Původně jsem si myslel, že to tak má fungovat - UDP kanál otevřený klientem by ml projít přes NAT, ale asi to nebude úplně tak jednoduché. Pokud si pamatuji, tak jsem pro komunikaci klient-server používal jen jeden port. Asi si zkusím udělat malý test.

[geby]

Kdyby to tak nebylo, tak ti nefunguje vůbec nic, ani DNS.

[geby]

Obecně se nejvíc chybuje právě ve způsobu, jakým posíláš odpovědi na UDP. Lidi plavou v pojmech IP, port, socket, a pak v programech vyrábějí neuvěřitelné věci. :-)

Bohužel, plavou v tom i mnohem větší profici. Dneska když pátrám po tom, co povolit na firewallu, tak se i od renomovaných firem dozvím odpověď typu: "stačí povolit port 12346". A já se obratem zeptám, jestli mají na mysli TCP, UDP, nebo něco jiného? Už bych mohl mít galerii nechapavych obličejů!

[pf1957]

To musí dělat tak často, aby se ta rezervace na NAT nezrušila pro nečinnost.

V tomto kontextu mi neni jasne, jak "budi" NAS (Synology) ze spanku, kdyz mi tu nekolik dni spi a pak udelam request pres jejich public server quickconnect.to, tak ji probudi. Znamena to, ze i kdyz spi, tak neuspi LAN adapter a udrzuje ten NAT zivy?

[raul]

Nebude tohle napsany v js z tveho prohlizece na lokalni siti ? (Z legrace jsem to ted zkusil a byt find.synology.com nic nenasel, tak v pozadavku get dostal synology, ktery mam doma a jsem pripojen k vpn zde i doma. Nicmene, tudiz to asi nehleda nejaky prihlaseny synology na me ip, neb tady je zde i doma ted jina. Pak to asi zfiltroval, ze zde mame jiny ip rozsah nez doma a neukazal nic. Nicmene, nasel i syno pres VPN)

[pf1957]

Nebude tohle napsany v js z tveho prohlizece na lokalni siti ?

Urcite ne, protoze se to vzbudi i pres apku v mobilu, ktera v lokalni siti neni. Navic, kdyz zadavam URL na quickconnect.to, tak v browseru nic spolecneho se synology nebezi - tam se objevi az obrazovka prpo login. Kdyz uz je to vzbuzeny a pripojuju se z lokalni site, tak to pouzije jakoby hairpinning

[raul]

Ouk, jen napad..

[Jan Fiala]

V tomto kontextu mi neni jasne, jak "budi" NAS (Synology) ze spanku, kdyz mi tu nekolik dni spi a pak udelam request pres jejich public server quickconnect.to, tak ji probudi. Znamena to, ze i kdyz spi, tak neuspi LAN adapter a udrzuje ten NAT zivy?

NAS nespí úplně, část ho funguje, už kvůli tomu buzení ve vnitřní síti. Klidně může fungovat i tak, že se občas koukne na server a pokud tam má požadavek, tak se probudí, nemusí přímo udržovat spojení aby byl "pushnut" a probuzen zvenku. A tobě těch pár sekund čekání divné nepřijde.

[geby]

A navíc existuje uPNP. Pokud je na routeru zapnuté, tak si zařízení na vnitřní síti dokáže samo nastavit port-forward na routeru.
Nevím, jaké přesně Synology máte na mysli, to moje je asi trochu větší, a uPNP u toho zapnout jde.

V každém případě tam ale musí běžet něco, co opravdu poslouchá. A občas něco posílat je už zanedbatelný problém.

[pf1957]

Mam nejakou 4 diskovou, tusim DS4xxj, ale ani UPNP, ani WOL nemam v konfiguraci povoleny, takze to nejspis bude tak, ze to jen zastavi disky, vetraky a zhasne LEDKy a poluje ten public server :-) Ostatne jako hafo ruznych zarizeni, kterym clovek wattmetrem nameri skoro stejnou spotrebu, bez ohledu na to, ze se tvari, ze spi.