Jak na serveru poznat, ze spadl klient?

Miroslav Prymek prymek na tiscali.cz
Pondělí Březen 24 16:19:14 CET 2003


"Stanislav Meduna" <stanom na etm.at> wrote in message
news:1048514208.801251 na newsmaster-03.atnet.at...
> Lutujem, toto je jedine riesenie. TCP nie je stavane na rychle zistenie
> stavov ako "niekto vytiahol kabel od sietovky", "spadol firewall kde bezi
> maskarada" alebo "zosypala sa klientska masina". Promptne sa dozviete
> iba korektne zrusene spojenie. TCP keepalives sa prilis nehodia -
> nie kazdy OS ich umoznuje rozumne ovladat.
>
> Vlastny keepalive protokol je jedinym spolahlivym riesenim. Been there,
> done that (a nie raz)...
>
> Tiez moze pingat klient a ak serveru pocas nejakeho intervalu nic
> nepride, tak spojenie zrusi.

Mam pocit, ze stejny problem je dokonce i pri koreknim zavreni socketu
(ale jeste jsem to dukladne netestoval).

SITUACE: Server prijme pozadavek, odpovi na nej a ceka dalsi (od stejneho
klienta).
Jelikoz socket je nastaven jako blokujici, thread je uspan (nejsou data).
Jestlize
klient v teto "dobe uspaneho serveru" socket zavre, server kliedne spi dal.
(ocekaval bych, ze dostane nejaky signal - nejspis SIGPIPE, nebo vrati
EPIPE)

RESENI1: Pouzit neblokujici socket. To se mi ale moc nechce, protoze ho pak
musim
periodicky kontrolovat, coz znamena systemove prostredky, narozdil od
blokujici verze.
(P.S. doufam, ze po volani usleep v ramci cyklu kontrolovani zda nejsou
nejaka data
je proces opravdu uspan a zadne prostredky nepotrebuje). Pokud je nastavena
dostatecne
dlouha doba pro usleep, tak to ani moc prostredku nesezere, akorat se muze
prodlouzit odezva serveru.

RESENI2: (pouze pokud implementuji svuj protokol) Klient na konci komunikace
posle neco, co bude znamenat, ze konci a server tedy socket s klidem zavre
sam.

Ja jsem pouzil reseni2, ktere ale teda bohuzel moc dobre nefunguje, pokud se
klient chova nekorektne, popr. spadne.
Co vy na to? Slo by to nejak lip?

MP




Další informace o konferenci Linux