Sziasztok!
Kerdes: UNIX domain socket-ek ko"re'ben a `connection reset by peer` (ECONNRESET) pontosan mit takar, mikor fordulhat elo"? Ha ket program kozul az egyik (konkretan a kliens) szepen bezarja, majd kilep, szabalyosan (main() leall), akkor a szerver oldalon a read() nem 0-val hanem -1 + ECONNRESET-tel te'r vissza. Semmi extra konfig (setsockopt?) nem volt a szerver/kliens socket-en, a szerveroldali algoritmusban semmi nagy durranas nincs, a valgrind nem jelez semmi problemat, es ha kezzel beleteszem a protokolba, hogy a kliens "koszonjon el" es a szerver bontsa a kapcsolatot, akkor meg minden fasza (alatamasztando, hogy nem az algoritmusba kerult pl. hibas pointerkezeles altal pl. felulirt memoria kavar be).
Szoval a konkret problema ez, de altalanossagban is erdekel, hogy mi kozhat conn. reset-et egy ilyen (legalabbis elsore) egyszerunek tuno objektumon mint unix socket. Mondjuk ha az egyik oldal aborta'l vagy sigsegv hatasara all le, akkor oke, ugy el tudom kepzelni, de itt semmi ilyenrol nincs szo...
koszi, A.
szerk: c/c++ kornyezet nem tudom mennyit szamit, csak azert valasztottam ezt a kategoriat mert a problema ebben a kornyezetben merult fel (C progi), de az alap-kerdes persze nyelv-fuggetlen...
Fórumok
Hozzászólások
Tapasztalatom az, hogy ha a szerver, tehát amelyik accepteld, az zárja le close()-val a socketet, akkor a kliens read()-ja nullával tér vissza, ha a kliens, tehát amelyik connect()-elt, zárja le close()-val a kapcsolatot, akkor a szerveren ECONNRESET lesz az eredmény.
De a szerver ezt egy if()-fel simán tudja kezelni.
Ha saját "elköszönési" protokoll nélkül akarod a kliensről lezárogatni a socket()-et, akkor próbáld ki, hogy a close() előtt shutdown()-olsz a socketen. Hátha akkor nem lesz ECONNRESET, most nem emlékszem így hirtelen.
Hm, ezt most kiprobaltam egy gyors peldan (az socket parancs unix socket kezelesere peccselt verziojaban ill. siman inet socket-ekre), es mintha ott mukodne. Szoval lehet hogy megsem teljesen ez, bar ott lehetnek me'g fura dolgok.
Azert me'g nyomozok... koszi, ez a shutdown() mindenkepp probara erdemes.
Figyelj, olyan nagy feneket ne keríts azért a dolgonak (nem érdemes - sok eltérő rendszer, eltérő implementáció, lehet, hogy vannak pici eltérések), inkább valahogy így írd meg a programot, így tutira mész. :)
int readval;
...
...
readval = read(....);
if (!readval || (readval==-1 && errno == ECONNRESET)) {
printf("socket closed, client logout.\n");
...
...
return;
} else if (readval==-1) {
printf("FATAL ERROR: read() error: %d %s\n",errno,strerror(errno));
...
...
return;
}
process_data_from_socket(...);
...
...
(Azért javaslom, hogy close() előtt mindig hívj shutdown()-nt, az kiküldi a pending buffereket - lehet, hogy a FIN flag csak ekkor megy ki egy TCP keretben, mert egyébként nincs éppen kimenő csomag, amire ráültetné a TCP/IP stack, és ez jelezné a másik oldalon, hogy lezárták a socketet, és a read ekkor adna vissza nullát. - Persze ez csak az én gondolatom, ki tudja, hogy vannak öszekókányolva a TCP/IP stackek. :) )
(Bocsesz, space-vel húztam be a sorokat, mégis eltünt a formázásom. :( )
Asszem a [ code ] es a <code> tagek nem ugyanazt hozzak ki a drupalbol.
--
Ez jól kapcsolódik...
Igen, mert en elolvastam azt is, amit az utolso sorban zarojelek kozott irt, te meg nem.
--
/usr/src/linux/net/unix/af_unix.c:
úgytűnik ezzel van összefüggésben:
skb_queue_empty(&sk->sk_receive_queue)
Aha, de ez nem datagram socket-ekre vonatkozik? Az, hogy az address family az unix, a socket maga me'g stream. Igen, es ennek tobb ertelme is van, marmint hogy egy datagram-nal ha a masik fe'l bezarja maga't (es persze af_unix, tehat a kernel kvazi tisztaban van ezzel), akkor nem tehet mast, mint econnreset-et dob. Stream socket-eknel (meg ugy enbloc, file-oknal, pipe-oknal, ...) meg az kell legyen a normalis, legjobb tudomasom szerint, hogyha a masik fe'l zar (ami egy szabalyos dolog, szoval szabalyosan za'r), akkor az egyik fe'l 0 hosszusagu szabalyos adatot olvas ki (tehat nem connreset). Plusz persze select()/poll() is visszate'r, ha az fd a read set-ben van. Ha erre persze me'g 1x raolvasna valaki, akkor mar lehet hibaval is visszajonni, de eloszor nem.
Az erintett kodreszlet ez, ahol a szerver socke-tet megcsinalja a cucc:
A.
Az első kód az nyilván datagram-os socket, de a unix_release_sock szerintem dgram-os és stream-es is: (de az is lehet, hogy egész rossz helyen keresgélek ... :) )
Találtam egy ilyent (unixstrserv, unixstrcli)
Ez egyébként a "Unix Network Programming - Volume I"-nek a melléklete!
Aha, thx, megnezem majd. Egyelore a problema a protokol (egyebkent szuksegszeru") modositasaval megoldodott, mindenesetre majd jo lenne rajonni, mert akkor is furcsa.