Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Waseihou 18. 06. 2012, 17:51:21
-
Zajímalo by mě, jak co nejlépe (ne nutně nejjednodušeji) vyřešit problém NATu, tedy spojit dva klienty za routerem který používá NAT a klienti naprosto nemají šanci cokoliv změnit, tedy třeba přesvědčit ISP aby mu namapoval port. Jde mi tedy o to jak co nejlépe nakombinovat existující knihovny které slouží k tomuto účelu, jazykem použitým pro takový program by mělo být C/C++ a nebo by měl existovat port. Nalezl jsem několik řešení, ale žádné nevyužívá všechny techniky co pro toto existují, o multiplatformnosti nemluvě. Každopádně řešení MUSÍ fungovat i pod Windows, protože tam je největší potenciální uživatelská základna pro to co chci.
Hlavní požadavek: Mějme aplikaci kde uživatelé mají 160bitový identifikátor, třeba SHA1 jejich MAC adresy. Požadavkem je aby se kterýkoliv uživatel mohl přímo spojit s jakýmkoliv jiným bez ohledu na to, kde se ve struktuře sítě nachází, ať již za NATem a nebo mají veřejnou IP. Předpokladem je že existuje alespoň jeden uzel overlay sítě s veřejnou IP, ten by ale neměl být použít jako proxy, nanejvíš nějak dopomoci ustavení spojení. Komunikace musí být asynchronní, ale to je snad standard.
Co jsem nalezl:
libnice: http://nice.freedesktop.org/wiki/ - jde prý zkompilovat i pod Windows, dle zdrojáku si asi trochu rozumí i s UPnP, ale podpora pro NAT-PMP zatím chybí.
libjingle: http://code.google.com/p/libjingle/ - mělo by se umět dobře dostat přes NAT, ale prý je to prasácky udělaná knihovna plně nekompatibilní s Jingle protokolem a po té co to Google zveřejnil tak toho hodně změnil na své straně, nevím jestli tuhle a nebo libnice
miniupnp: http://miniupnp.free.fr/ - umí komunikovat s routerem podporujícím UPnP (ale už ne dva UPnP routery za sebou, časté v mnoha domácnostech...) a má v sobě i NAT-PMP podporu
ICE/zeroc: http://www.zeroc.com/ - zdá se pěkné pro tvorbu distribuovaných aplikací, pěkný example chatu a podpora mnoha jazyků
zeromq: http://www.zeromq.org/ - odlehčená alternativa k ICE
boost/asio: http://www.boost.org/doc/libs/1_49_0/doc/html/boost_asio.html - asi nejjednodušší na použití, multiplatformní, podpora NATu nejistá
Tak - a jakým způsobem tyto knihovny nakombinovat a schovat je pod nějaké další rozhraní, které si samo určí co použije.
Rozhraní (dejme mu název třeba bitlegion) bude mít pouze tyto funkce :
1) inicializace a ukončení - nějaké bitlegion_init() a bitlegion_exit()
2) získání bloku dat podle jeho sha1 hashe - handle = bitlegion_getblock_async(sha1_hash) které vrátí "něco" pro kontorlu jestli data už dorazila
3) bitlegion_check(handle) => enum {SEARCHING, SUCCESS, NOT_FOUND} - tedy něco na kontrolu hledání bloku, jestli zatím hledá, byl získán, a nebo nebyl nalezen
4) bitlegion_get_data(handle, &pdata, &pdatasize) pro získání dat
takže to bude fárat
main() {
BitLegion bl = bitlegion_init(...); // connect etc.
...
handle = bitlegion_get_block_async(bl,"BL5OM7M75DWHAXMFZFJ23MU3LVMRXKFO6HTGUTY");
...
stop = false;
while (!stop) {
if (bitlegion_check(bl,handle)) {
bitlegion_get_data(bl, handle, &data, &dataSize);
stop = true;
}
}
... // use data
bitlegion_exit(bl);
}
BTW jaký je váš názor na architekturu navrhované "knihovny", je to vhodný přístup? Zas tolik zkušeností nemám abych to byl schopen rozhodnout, jestli je to dobrý návrh pro knihovnu která má umožnit získávat bloky dat na základě jejich hashe.
Mimochodem nějaký týpek se snaží o něco podobného, tak ho nějakou dobu sleduji, ale neřeší NAT traversal a používá boost asio a ani nemá představu o struktuře overlay p2p sítě (já chci něco na způsob chordu - tedy DHT, a ne jen friend to friend): http://bithorde.org/
-
Jo jinaj si spíš představuji že ta knihovna se bude připojovat ke službě která poběží pod OS tak aby ji teoreticky mohlo využívat vícero různých aplikací, tedy půjde o middleware jehož jediným účelem bude získávání a ukládání bloků dat podle jejich hashe do nějakého distribuovaného úložište, samotné rozhraní ale nebude řešit odkud se data berou. Bloky dat nemají garantovanou žádnou životnost, málo používané kousky mohou ze sítě zmizet. Pokud má někdo nápad jak toto vyřešit elegantně, tak sem s ním...
-
A taky bych to mělo umět použít IPv6, tedy když budou oba uzly sítě za NATem a budou se potřebovat spojit a nebude fungovat ani žádná NAT traversal technika ale bude nějak dostupné IPv6, tak aby ho použili. Tudíž fakt nakombit to jak jen to jde, využít každou dostupnou cestičku. S "proxy" řešením a lá TURN jsem ochoten se smířit jen pro ty nejhorší případy jako poslední možnou variantu.
-
Nainstaluj si Skype ;D
-
Skype API bohužel neumožňuje posílání souborů, ne že bych tuhle variantu nehledal, vím že jako VoIP aplikace to maj celkem pořešený ;)
-
Skype API bohužel neumožňuje posílání souborů, ne že bych tuhle variantu nehledal, vím že jako VoIP aplikace to maj celkem pořešený ;)
Já teda nevím, ale přes Skype se posílají soubory zcela běžně.
-
Ale nedá se udělat aby nějaká další aplikace využila Skype pro přeposlání dat jiné aplikaci na druhé straně, tedy využít toho že maj vyřešený NAT traversal.
Možná jsem to špatně vysvětlil - bude existovat p2p síť podobná třeba eMule, ale klienti budou sdílet nikoliv soubory ale pouze bloky dat konstantní velikost. Každý klient bude mít SHA1 hash svojí mac adresy jako identifikátor a pro každý blok dat bude vypočítán jeho SHA1 hash a uložen u těch kleintů sítě, jenž mu budou dostatečně blízko podle nějaké metriky.
Struktura sítě by měla být inspirována chordem: http://en.wikipedia.org/wiki/Chord_%28peer-to-peer%29
a nebo spíše Alt2Netem, což je chord chordů chordů pro lepší škálovatelnost...
Taky se nebude nijak řešit vyhledávání mimo hashů, jde mi jen o to vymyslet jak realizovat distribuované úložiště. Pro vyhledávní by se dalo použít toto: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.165.6185&rep=rep1&type=pdf
ale to teď nechci řešit. No alespoň je tam vysvětlený ten Chord...
Už mám v hlavě teorii jak má vypadat struktura této overlay p2p sítě, teď dát dokupy jak to zhruba naimplementovat a co nejvíce využít dostupná open source řešení.
-
Není jednodušší rozběhat zprostředkující server s veřejnou IP?
-
Ne, protože v případě příliš mnoha klientů by byl příliš vytížený, a stejně je nejlepší přímé spojení. Pokud jde o zprostředkování samotného navázání spojení, tak to samozřejmě počítám s veřejným serverem který pošle pakety tak aby se navázalo spojení mezi dvěma klienty za NATem, ale dále pak už komunikují přímo mezi sebou klient1-router1-...-router2-klient2.
Jinak by to šlo udělat i přes ten zprostředkující server který by přeposílal přímo data a fungoval tak jako proxy. Dejme tomu že by se všechny uzly sítě rozdělily na dvě množiny - ty které mají veřejně dostupnou IP adresu a ty které ji nemají. Potom by ty s veřejnou IP adresou vytvořily novou topologii jako v chordu - tedy všichni do kruhu podle svého ID které je hashem jejich MAC adresy a každý má navíc routovací "finger" tabulku na uzly které jsou od nich na kruhové topologii vzdáleny 1,2,4,8,16,...,2^n skoků takže adresu libovolného z nich lze získat v čase O(log(N)). Když by někdo za NATem hledal svoji "proxy" tak by požádal jiný veřejný uzel o její přidělení, což by se dalo udělat třeba tak že by tento vygeneroval náhodný hash a našel veřejný uzel s největším menším ID než je ten hash. Protože každý veřejný uzel by měl stejnou pravděpodobnost že bude vybrán jako proxy, došlo by rovnoměrnému rozložení zátěže. Jeden pasiv by dokonce mohl mít více proxy aby tolik nezávisel na rychlosti jednoho konkrétního uzlu a nebo by se vždy po několika požadavcích na bloky změnil proxy uzel.
Pokud by ale uzly s veřejnou IP sloužily pouze k ustavení spojení za NATem, tak by to bylo efektivnější a šetřily by si tak kapacitu pro ty největší nešťastníky. Za jistých okolností by jako proxy možná mohly fungovat i uzly za NATem, otázkou je co na to porty. To by ale mohla řešit topologie založená na hyperkostce takové že každý její uzel bude nahrazen kružnicí takže počet potřebných spojení na klienta by bylo omezené. - http://en.wikipedia.org/wiki/Cube-connected_cycles
-
Sice moc nechápu smysl projektu, no ale... třeba můžeš oživit tuhle zombie: http://samy.pl/chownat/
-
chownat je UDP hole punching, to umí i libnice včetně "simulace" tcp, zajímavěji však vypadá ten pwnat který používá celkem pěkný trik s ICMP pakety a který je podle všeho implementován také v gnunetu odkud by to šlo vykrást možná. Nic naplat, něco veřejného je stejně potřeba aby se získala veřejná IP routeru.
-
To je zase ten nápad s tím warézovým serverem, kde klienti nemají sdílet celý soubor, ale jen jeho fragment.
Což je IMHO naprostá blbost, protože to prostě není domyšlené.
Představme si sdílení DVD disku s kapacitou 4000MB, na sdílení takového obsahu je podle zkušeností z Torrentu potřeba nejméně 5x tolik uživatelů, aby ho vůbec bylo možné stáhnout. Tj. máme tu 5x4000 MB. Pokud u každého uživatele bude třeba jen to 1MB, jedná se o 20 000 lidí, které na začátku v síti prostě vůbec nebudou.
Dále tu je ten fakt, že ne každý je ochotný vyhradit na disku 1000 GB dat, naprostá většina bude uvažovat o vyhrazení cca 10GB dat. Část ostatních bude uvažovat možná o 100GB a pár nadšenců možná vyhradí celý disk. A jakmile budou potřebovat místo, zabrané místo smažou.
Pak tu je ten fakt, že v síti, kde se všechno propaguje mezi všechny, nemá nikdo za nic odpovědnost.
Nikde není celá image a bude potřeba udržovat až příliš kopií každé pitomosti.
Už jen abych si takovou síť vyzkoušel, zkusil bych zpropagovat svojí videotéku němých Ruských filmů na BlueRay.
66 filmů * 25GB.
No a protože nikdo vlastně netuší, co má na disku za bordel, nemůže to jen tak smazat.
Ale NAT problém není.
Navíc doba torrentů je dávno někde úplně jinde, v USA i Francii už dávno stačí k odsouzení jen prosté podezření.
-
Zajímalo by mě, jak co nejlépe (ne nutně nejjednodušeji) vyřešit problém NATu, tedy spojit dva klienty za routerem který používá NAT a klienti naprosto nemají šanci cokoliv změnit, tedy třeba přesvědčit ISP aby mu namapoval port.
Sednout si do kouta a počkat až to přejde.
Problém propojit dva klienty oba za svým NATem se řeší od počátku NATování a zatím se to nikomu uspokojivě vyřešit nepodařilo, leda tak dílčí úspěchy.
Řeší se to politicky, uživatel který není schopen proroutovat veřejné IP:Port má omezené služby.
-
No pokusit se něco takového udělat nemusí být špatné, nemá cenu přemýšlet jestli to bude fungovat, důležité je soustředit se na to jak to naprogramovat. A proč by se tam musely ukládat zrovna filmy? Dovedu si NAD TÍM představit třeba aplikaci na sdílení scanů skript mezi studenty, tam bude náročnost řádově nižší. Další možností by byla p2p cache pro bittorrent, často stahované bloky oblíbeného obsahu by časem v síti převážily a pomohly tak snížit nároky na zahraniční konektivitu. Komerční řešení pro p2p caching už existují a dělají přesně toto, pokud tedy uživatel tahá bez šifrování any to ISP mohl prohnat transparentní proxy cache.
Ale účel neřeším, chci se dopracovat alespoň k alfa middleware verzi kvůli získání zkušeností, to je celé. A middleware nebude mít "účel", bude to pouze služba. Pokud se někdo pokouší o něco podobného - viz. http://bithorde.org tak to není až tak dementní nápad. Jinak jde jen o další distribuované úložiště, podobný nápad je realizován třeba v http://project-voldemort.com/, což je také velká distribuovaná hash tabulka, akorát vhodná spíš pro bussinessy kde servery většinu času jedou a ne že se náhodně připojují a odpojují.
Takže otázka je - existuje distribuovaná hashovací tabulka využívající diskový prostor uživatelů-dobrovolníků která realizuje naprosto jednoduchou službu 1) nahraj blok dat a získej jeho hash 2) stáhni blok dat podle hashe ? Nic víc, nic míň? Tedy p2p distribuovaná varianta berkeley db?
-
Jinak v rámci své obsesivně-kompulzivní eskapády jsem narazil na mnoho zajímavého, tak proč se nepodělit ;)
třeba p2p web cache:
http://www.coralcdn.org/
http://en.wikipedia.org/wiki/Coral_Content_Distribution_Network
a jak se to používá? - přidá se na konec web adresy .nyud.net
takže na root se třeba jde: http://www.root.cz.nyud.net/
možná jsem blbej a nemám přehled o všem co se na netu vyskytuje, takže otázká zní: Kdo tohle neznal?
-
nyud je klasika, nicmene pouha public reverzni proxy, podobne jako ruzne anonymizery. neni to p2p storage ve smyslu ze kazdej dela coral cache node, ale musis byt v jistem univerzitnim kabalu kde se ten protokol pouziva.
mimochodem, akamai pouziva neco velmi podobneho coralu na jejich cdn, takze to uz zdaleka neni jen akademicka hracka.
jinak pwnat nepotrebuje *zadny* centralni bod. jelikoz delas overlay network, ukladas si proste nody s flagem ze maji verejnou ip a port. oni ti naz5 pak tvoji IP bonznou.
problem pwnatu spociva v tom ze pod masoxem/luniksem je problematicke posilat zmrsene icmp na kterejch to stoji, zkratka musis resit implementacni detaily pod kazdym os.
pro korektni implementaci solidniho p2p protokolu bych take potreboval nejakeho hybrida pwnat/libutp, nicmene neco rozumne fungujiciho sem nenasel, takze prznim stary dobry torrent...
pokud budes patlat v C neco ve stylu vyse uvedeneho (pokud mozno jako libutp kde je vse abstraktni, IO si musi delat uzivatel sam), hod to prosim nekam na github, docela by me to zajimalo.
-
K původní otázce: Co takhle použít IPv6 a ošetřit si případné zapnutí Teredo klienta. Teredo má veškerý NAT traversal v sobě vyřešený, takže aplikace jen otevře šestkový soket a nestará se.
Jen je potřeba nějak vyřešit objevování Teredo adres protistran.
-
Nějak jsem nepochopil dotaz tazatele, ale s NATem mám následující zkušenosti. Psal jsem si vlastní systém pro VPN ve stylu N2N, zejména pro přecházení mezi NATy. Bohužel to není tak snadný, kromě tedy nutnosti mít centrální bod na udržování směrovacích tabulek (MAC: IP: port). Vlastní VPNka fungovala jednoduše. z Tap přišel paket a pokud aplikace věděla, kam ho přeposlat, tak ho přeposlala, pokud to nevěděla, poslala ho na centrální bod. Ten jej přijal, k paketu přibalil IP adresu a port odkud paked přišel a rozeslal ho všem přihlášeným klientům. Klienti si pak k MAC adrese odesílatele přiřadili IP adresu a port. Pokud chtěli komunikovat obráceně, udělali totéž a postupně se takto prorazila díra. Přesný postup je trochu delší na psaní.
No a ty problémy: Dost často narážím na symetrické NATy. Tam vám nepomůže ani svěcená voda. Symetrický NAT přidělí port (a někdy IP adresu) různou i stejným klientům, pokud jejich pakety směřují na jiné cíle v internetu. Pak se díra nedá vytvořit. Ten můj systém si s tím poradí, ale bohužel to pak všechno posílá přes centrální bod.
Co se tereda týče, tak platí totéž u symetrický natů se na dvouch teredo IPv6 adresách nedomluvíte. Prostě se neuvidí, nepingají, netraceroutují. Přes centrální bod si to nepošlou. Zkoušel jsem miredo vůči teredu ve windows. Pokud dám teredo vůči freenet6, tak bez problémů. Přes třetí stranu se dvě tereda spojí, ale přímo ne (platí pro symetrické naty)
A kde jsem viděl symetrické naty? Seznamácká firemní síť,... a třeba mobilní síť Vodafone. Zpravidla velké NATované sítě.
-
Zatím si hraju z libnice která se zdá jako nejschůdnější varianta, cosi jsem zkompiloval ale nic to nedělá, plně to zatím nechápu. No po zběžném nahlédnutí se zdá že se dovede pokusit použít i IPv6 a trochu snad laškuje i s UPnP, alespoň jsem tam něco s tímto nápisem myslím viděl, ale nevím přesně.
Další c knihovna co prý tohle umí velmi dobře řešit je
PJNATH: http://www.pjsip.org/pjnath/docs/html/index.htm
která taky řeší ICE: http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment
ale tam už ty examply nechápu vůbec, ale pochopil jsem že pokud selžou všechny metody tak je třeba použít jakýsi TURN server který musí mít veřejnou IP adresu a slouží právě k přeposílání těch paketů mezi dvěma uzly které jsou za tou nejhorší variantou NATu. Takovéto řešení má myslím Skype který všechny případy kdy to jde taky spojí tou nejlepší možnou variantou, a kde to nejde tak použije svoje servery jako mezičlánek.
Neví někdo jak tyto knihovny použít? Google nenašel žádný dostatečně jednoduchý example ani tutorial...
Sakra je rok 2012 a stále není uspokojivě vyřešen problém jak spojit dva LIBOVOLNÉ počítače v internetu? No to snad ne! Nebo bohužel ano :(
-
No ještě prohledám api přímo pjsip: http://www.pjsip.org/
má to hodně zajímavé objekty součásti:
pjlib: http://www.pjsip.org/docs/latest-2/pjlib/docs/html/modules.htm
pjlib-util: http://www.pjsip.org/docs/latest/pjlib-util/docs/html/modules.htm
-
Sakra je rok 2012 a stále není uspokojivě vyřešen problém jak spojit dva LIBOVOLNÉ počítače v internetu?
NAT není internet.
V internetu se dají propojit dva libovolné počítače z principu funkce internetu a protokolu IP.
-
Ale za NATem je dnes tolik potenciálních uživatelů, že se bohužel nedá ignorovat. Bohužel. Zajímalo by mě kolik člověkohodin již muselo být vynaloženo na řešení tohoto "problému", a kolikrát třeba i v privátní sféře opakovaně vynalézat kolo. Komerční knihovny pro NAT traversal existují taky, včetně možnosti pronájmu TURN relay serververů pro zajištění plné konektivity. Pak se člověk nemůže divit úspěchu cyberlockerů, centralizované řešení má za této situace navrch.
-
Ale za NATem je dnes tolik potenciálních uživatelů, že se bohužel nedá ignorovat. Bohužel. Zajímalo by mě kolik člověkohodin již muselo být vynaloženo na řešení tohoto "problému", a kolikrát třeba i v privátní sféře opakovaně vynalézat kolo. Komerční knihovny pro NAT traversal existují taky, včetně možnosti pronájmu TURN relay serververů pro zajištění plné konektivity. Pak se člověk nemůže divit úspěchu cyberlockerů, centralizované řešení má za této situace navrch.
Vyplýtvalo se na to neuvěřitelné množství času a nic zaručeně spolehlivého neexistuje, dílčí úspěch je UPnP.
Psal jsem to dříve, amatér co je neschopen protunelovat IP:Port bude mít omezené služby, v DC++ tento tlak na uživatele fungoval skvěle a to byste se divil jak to najednou jde, když je potřeba stáhnout porno ;-)