14 lines
3.0 KiB
Plaintext
14 lines
3.0 KiB
Plaintext
|
Failover stratégiák (ötletek):
|
||
|
|
Ha van már felderítő módszerünk, akkor a consumer több producert is felderít (és akár a háttérben időnként ellenőrzi a kapcsolatot velük) és ha megszakad a kapcsolat azzal a producerrel, akitől éppen tölt le, akkor kapcsolódik egy másikhoz a listából. Azt is lehet, hogy a producerek is felderítenek, és amikor kapcsolódik hozzájuk egy consumer, akkor kicserélik egymással az információjukat. Lehetséges az is, hogy nem tárolunk listákat és mindig amikor megszakad a kapcsolat, a consumer keres egy új producert.
|
||
|
|
Fájlok azonosítása mehet valamilyen ID pl. hash segítségével. Ha egy producertől két consumer ugyanazt a fájlt tölti le, akkor lehet pl. azt, hogy az elsőnek az elejétől adja a fájlt, a másodiknak a végétől és megosztja az IP címeiket egymással, hogy ha kiesik, akkor a meglevő részeket ki tudják cserélni maguk között. Consumer egy másik consumertől is tölthet le, ha éppen nincs producer, akinél meg lenne a szükséges fájl, de consumer van (és felderítette).
|
||
|
|
Ha feltételezzük, hogy csak alhálózaton belül működik a felderítés (pl. ARP cache-ből kiszedegetve IP címeket), akkor alhálózatok között pl. valamilyen szerver segítségével működhet a dolog, akihez mind a két alhálóból becsatlakoznak vagy akkor, ha az alhálózat címek statikusak (és nem NAT-oltak) és pl. adott alhálózaton egy konkrét címre küldünk valamilyen csomagot, amit lát az alhálózaton belüli többi host (nem kell, hogy legyen bármi azon az adott címen), a forrás IP-re tudnak akkor vissza küldeni felderítő csomagokat.
|
||
|
|
Ha egy consumer nem talál producert, akkor akár azt is lehet mondani, hogy egy ember kézzel adjon meg egyet, ahhoz csatlakozik és elkéri a listáját.
|
||
|
|
Gnutella esetén van egy node lista a hoston (ez előre meg van adva, ezért az esetünkben nem nagyon tud működni, mert nekünk dinamikusak az ip címek) és ezt folyamatosan frissíti az elérhető node-okkal.
|
||
|
|
Torrent esetén tracker, de a DHT jól hangzik: https://stackoverflow.com/questions/1332107/how-does-dht-in-torrents-work ; https://en.wikipedia.org/wiki/Kademlia
|
||
|
|
Nem úgy néz ki, hogy ismert, közvetlenül elérhető szerver nélkül megoldható, hogy két különböző NAT mögötti host tudjon egymással kommunikálni. Szerverrel több megoldás is van:
|
||
|
|
TURN: a szerveren keresztül megy az adat: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT
|
||
|
|
STUN: a szerver csak összekapcsolja a hostokat (de ez nem mindig működik): https://en.wikipedia.org/wiki/STUN
|
||
|
|
//Teredo is használ egy jól ismert szervert: https://en.wikipedia.org/wiki/Teredo_tunneling
|
||
|
|
NAT-ba csatlakozás pl. SSH tunnel-el (ehhez kell az, hogy kifele legyen kapcsolat és a benti host ismerje a kinti hostot): https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work
|
||
|
|
Kazaa-ban is supernode-ok vannak, telepítéskor ismerni kell ezek közül párat: https://computer.howstuffworks.com/kazaa3.htm
|