vonalszakadás után tcp folytatása

Hálózatok egyéb

Sziasztok!

Van olyan szoftveres megoldás, amellyel folytatni lehet egy tcp sessiont, ha a kliens és a szerver közötti pl. bérelt vonal 1-2 percre megszakad? (és persze nincs másik route)

Vagy csak állítgassam a tcp timeoutokat?

köszi

  • 1439 megtekintés

( apal v | 2008. 09. 25., cs – 18:00 )

Ha a szakadas elott a kliens (es szerver) ip-je nem valtozott _es_ a kliensoldalon valami csunya demon nem piszkalta az interface-t (ifconfig ethx down/up), akkor egy ido utan helyre kell alljon a kapcsolat (az ido fugg a timeout-oktol). Ha valtozott az ip-cim vagy az iface leallt/ujraindult akkor nem valoszinu. Ezesetben egy udp alapu vpn segithet, amennyiben a vpn kliens - es az asszocialt tun/tap eszkoz - tuleli a kimeneti iface leszakadasat.

De ez is csak akkor igaz, ha a szakadás alsóbb hálózati layerben történt, mert ekkor van esély rá, hogy a stack implementációja recoveryt csinál. Ha maga a kommunikációs partner lesz kilőve (pl. kill), akkor általában a kapcsolat is lezárul. Innen már application layerben kell hogy legyen valami resume opció.

--
The Net is indeed vast and infinite...
http://gablog.eu

( fazik | 2008. 09. 25., cs – 19:08 )

eddig is köszi, de pontosítanék:

- ip-k nem változnak közben, de a kliens lehet windows is
- a szakadást értsük úgy, mintha elvágták volna a kábelt arra az időre, azaz semmi nem megy át
- a két oldalon a processzek továbbra is futnak
- ugyanazt a sessiont kell(ene) folytatni

Tehát szerintetek ilyen feltételekkel elég a timeout növelése?

Tehát szerintetek ilyen feltételekkel elég a timeout növelése?
Akkor elvileg igen. Ki kell probalni, hogy a kapcsolat hogy reagal a halozat kiesesere (konkretan pl a madzag kihuzigalasaval :]). Ez nyilvan fugg a protokolltol is, marmint mas lesz az ido" ha a kliens/szerver folyamatosan kuldi a kieses alatt is az adatot (ugye egy tcp socket-re valo iras azt mondja hogy franko, kiment az adat, akkor is, ha szakadt a madzag, legalabbis egy darabig), es mas ha a protokoll eleve interaktivabb.

A.

hmm, és azokat a kimenőket addig nem lehetne pufferelni valamivel amig helyre nem áll a kapcsolat? Ugyanigy persze a masik irányt is...

szerk:
közben rájöttem, hogy ez, igy h*lyeség. Szóval olyasmit képzelnék el bármilyen tcpvel, mint a windowsos távoli asztal, azaz ha megszakad a kapcsolat akkor képernyő kicsit elsötétül, user vár, aztán ha újra jó a kapcsolat, akkor folytathatja.

hmm, és azokat a kimenőket addig nem lehetne pufferelni valamivel amig helyre nem áll a kapcsolat? Ugyanigy persze a masik irányt is...
De, a kernel, a TCP stack bufferel, valamennyit. Lasd `man 7 tcp`, /proc/sys/net/ipv4/tcp_*, itt allithatoak az algoritmus egyes parameterei. Van vagy 2-3 tucatnyi parameter, el lehet veluk jatszani, egy jo darabig ;)

windowsos távoli asztal
Azert a ket halozati reteg kozott van egy kis kulonbseg ;) egy kliensprogramba vagy egy protokolba 1000 mas dolgot is bele tudsz pakolni, hogy eszlelje kapcsolat allapotat (pl. a protokol teljesen master-slave: ha nem jon valasz 1 sec-en belul, akkor bukta; ha a connect() nem zajlik le 1 sec-en belul akkor bukta, stb). Atmenetkent talan a VPN lehet a jo, ha maga a kliens jol megirt, akkor jobban lereagalhatja a hulye helyzeteket.

Jó lenne konkrétan tudni, hogy milyen alkalmazásra és milyen okból keresel megoldást. Ha az indító hozzászólásban példaként felhozott viszonylag rendszeres bérelt vonali szakadozás van, akkor a bérelt vonalat kell megjavíttatni, és nem a TCP-vel kerülőmegoldásokat keresni. A TCP-nél arra is érdemes figyelni, hogy két végpontja van, így a timeoutok problémaköre nem csak a te helyi gépeidet érinti, hanem az összes, a külvilágban potenciális TCP peerként szóbajövő gépet, amikre nincs ráhatásod. Nem csak azt kellene kivédeni, hogy a te oldalad lezárja a kapcsolatot, hanem azt is, hogy a vonalszakadás ideje alatt a távoli TCP fél se tegye ezt. Példaként azt lehet felhozni, hogy egy nagyobb, mondjuk 30 MB-os file-t kellene letöltened FTP-n, és 2 MB lejövetele után 2 percre megszakad a vonalad. Az FTP szervernek is úgy kellene beállítva lennie, hogy ne legyenek ezalatt újraküldések, ne járjon le a keepalive, vagy legyenek kellően nagyok a windowméretek, illetve legyen a szakadozós vonal mindkét oldalán igen nagy a routerek interfész queue-ja. Ez nem nagyon életszerű. Az egyik hozzászólásban szóba jött a VPN is. Erre a problémára az sem megoldás. Aztán jön még az is, hogyha megszakad egy vonal, akkor az utolsó hop egy idő után visszajelez(het) a küldő félnek. Ugyebár ezt is ki kellene küszöbölni.

"olyasmit képzelnék el bármilyen tcpvel, mint a windowsos távoli asztal, azaz ha megszakad a kapcsolat akkor képernyő kicsit elsötétül, user vár, aztán ha újra jó a kapcsolat, akkor folytathatja."
A két dolog között van egy nagyobb különbség. A távoli asztalon a túloldalon futó programnak csak a képét látod, ami független a program futásától, mivel maga a futó program (nem az RDP szerverről van szó) nincs közvetlen interaktív hálózati kapcsolatban a képet megjelenítő klienssel. Végig lehet gondolni ugyanezt egy SMTP-n keresztüli félbehagyott levélküldésnél, egy félig letöltött weboldal folytatásakor.

Végül még egyszer visszautalva az első mondatra. Pontosan milyen ok miatt, milyen alkalmazásban és milyen protokollon kellene áthidalni?

Tiszta sor: a bérelt vonalat kell minél hamarább javítattni. Az egész akkor merült fel bennem mikor egy ideje már dolgoztak rajta és ugyanolyan rossz volt, azaz kb. 5-10 percenként megszakadt 1-2 percre.

Szóval: a bérelt vonalon keresztül lényegében csak egy ssh-s alkalmazást használnak a userek (illetve ez a legfontosabb), ennek kellene biztosítani ilyen esetekben a szakadásmentességét). De, gondoltam, nincs-e olyan megoldás ami minden tcp sessionre jó lehetne, függetlenül a magasabb szintű protokolloktól.

Mind a két oldalra van ráhatásom, igy persze timeoutot lehetne növelni.

Az rdp-s dolgot csak hasonlatnak, annak szemléltetésére szántam, hogy ideális esetben ilyen képzelnék el (a használt alkalmazás átírása nélkül persze, ha lehet).

A konkrét probléma megkerülésére használj screen-t.
Amúgy szakadós vonalon nekem nagyon jól működött, hogy két végpont közt felhúztam egy ppp interfészt, annak volt ugye két statikus címe, és az alkalmazások azokon a címeken kommunikáltak.
Ilyenkor, ha megszakadt is a kapcsolat, amin a ppp0 alapult, az alkalmazások nem vettek észre a dologból semmit, csak várakoztak. És amint újra volt kapcsolat, ment minden tovább. Nem egyszer sikerült így 10 percnél hosszabb "szakadásokat" is átvészelni. Persze windows esetén ez nem igazán megoldás...