Dotaz: write na TCP spojení neohlásí chybu

[Dave]

Zdravím,

programuju v C TCP komunikaci mezi 2 uzly, vše funguje jak má, ale mám problém s jedním chybovým scénářem. Ustanovím TCP spojení, pošlu data, která v pořádku dorazí k příjemci. Spojení nechám otevřené. Pak na odesílající straně zablokuju příjemce firewallem a opět pošlu data. Data k příjemci samozřejmě nedorazí, ale na odesílající straně write() hlásí, že komunikace proběhla v pořádku. Jak se dá na odesílající straně detekovat, že nastala chyba a data k příjemci nedorazila? Zkoušel jsem si hrát s nastavením socketu SO_KEEPALIVE, což funguje, ale přijde mi to jako obcházení problému a ne jeho řešení...

Odpovědi

[kovariadam]

Neslo by po prijati odoslat naspat nejaku ACK spravu? Co za data to su?

[Dave]

Jde o SIP protokol, komunikace mezi serverem a klientem, modifikovat protokol a přidat ACK bohužel nemůžu...

[Sten]

write nečeká na potvrzení, že data dorazila, pokud je v cache dost místa. Můžete zkusit použít TCP_NODELAY, ale ani to nezaručí, že se problém dozvíte hned.

[Dave]

TCP_NODELAY už jsem zkoušel, bohužel neúspěšně...

[Ivan]

Jen strilim od boku, zkousel jsi SO_SNDTIMEO? Uspesne zavolani write, znamena jenom to, ze kernel prijal data do sveho odesilaciho bufferu (popr. je jeste odeslal po siti). Kolikrat byla data retransmitovana po siti te nemusi zajimat. Hadam, ze ti vlastne vadi, ze mas v defaultu nastaveny velky connection timeout.

Zadne obecne reseni neexistuje. Pokud by firewally posilaly reject misto toho aby dropovaly packety tak by to fungovalo jak ma.

U SO_KEEPALIVE mas problem v tom ten timeout je globalni na urovni celeho OS, a neni mozne nastavit ho pro jedno konkretni spojeni.

[Sten]

U SO_KEEPALIVE mas problem v tom ten timeout je globalni na urovni celeho OS, a neni mozne nastavit ho pro jedno konkretni spojeni.

Ale lze: TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

[Dave]

SO_SNDTIMEO jsem zkoušel, ale bohužel to nezabralo. Problém je v tom, jak už tu bylo zmíněno, že write() skončí úspěšně po předání dat kernelu a ne až potom, co druhá strana data opravdu přijme.

SO_KEEPALIVE jde nastavit pro každý socket zvlášť, ale toto řešení přidává dodatečnou síťovou komunikaci, což v mém případě bohužel nemohu použít.

[Luboš Doležel (Doli)]

write() je u TCP spojení standardně tuším asynchronní, když ho přepnete na synchronní, tak už bych chybové návratové kódy čekal.

[Josef Kufner]

TCP negarantuje doručení dat. Pouze garantuje, že ty data dorazí ve správném pořadí a pokud bylo spojení korektně uzavřeno, tak budou všechna.

Tedy, pokud spojení uzavřeš, tak close() ti chybu vrátí. Do té doby nevíš nic (a není to špatně).

Pokud chceš mít jistotu, že nějaká zpráva byla doručena, pošli si ACK na aplikační úrovni a nespoléhej na TCP. Ono toho garantuje daleko méně než si mnoho lidí myslí, například Jabber takle ztrácí zprávy, když ti vypadne spojení (je to chyba v návrhu XMPP).

[pavlix]

Ono toho garantuje daleko méně než si mnoho lidí myslí, například Jabber takle ztrácí zprávy, když ti vypadne spojení (je to chyba v návrhu XMPP).

A nejde to ani dobře řešit přes TCP acky... ale naštěstí XMPP má definované jak aplikační acky, tak pingy, dělal to původně před pár lety Justin Karneges a byly kolem toho velké diskuze, kdy různí lidi vymýšlely totální cypoviny jako end-to-end potvrzování. Takže je to jen na lenosti implementátorů.

[Ondrej 'SanTiago' Zajicek]

Pokud chceš mít jistotu, že nějaká zpráva byla doručena, pošli si ACK na aplikační úrovni a nespoléhej na TCP.

Souhlas. Na druhou stranu TCP samo zajistuje potvrzovani doruceni dat, takze teoreticky by mohlo jit rozsirit API tak, aby toto potvrzeni bylo propagovano do aplikace.

[Ivan]

Nojo TCP potvrzuje data, ale samo si muze urcit jak velke baliky dat se potvrzuji. Podle me nemuzes spolehat ani na to ze ti prijde ACK pro kazdy packet s priznakem push (P).

[pavlix]

Tak on write proběhl v pořádku, data se odeslala. Pokud někoho odřízneš DROP, tak holt vytimeoutuje. Musel bys dát aspoň REJECT a doufat, že chybová zpráva dojde. Ale tvrdý rozpad TCP je prostě pomalý.

Technicky to jde řešit buď ověřováním TCP acků, což vůbec netuším jestli/jak je exponované... a nebo těch aplikačních acků.

Níže píšeš, že řešíš SIP, to je změna zadání. V dotazu máš TCP, takže jsi se zřejmě zeptal na něco jiného, než jsi chtěl. Chceš na TCP vrstvě řešit něco, co TCP standardně nenabízí, takže doporučuju poskočit na aplikační vrstvu a řešit to tam.

A vzhledem k tomu, že jsi zatím nenapsal nic o tom, že by s tím byl nějaký problém... tak není, co řešit :).