Jak na serveru poznat, ze spadl klient?

[Jan Kubik]

"Miroslav Prymek" <prymek na tiscali.cz> wrote
> Dobry den,
> mam aplikaci, ktera funguje jako server na protokolu TCP/IP. Tato
> aplikace odpovida na dotazy klientu, *nikdy sama komunikaci nezacina*.
>
> PROBLEM: Pokud klient spadne, nezavre socket, spojeni zustane vyset
> a na serveru zbytecne zustane thread, ktery ceka na pozadavky od
> klienta.
>
my uz 8 let pouzivame take blocking server s timeoutem pres inetd.
V podstate to funguje OK - server + 70 clientu.
pred read je alarm a po read se alarm vypne. Jestlize prijde signal
tak se to osetri kvuli hlasce - neb jak pravi klasik - skutecny programator
po
signalu ukonci program.
Client bezne posila v protokolu konec spojeni - ten konec je potreba na obou
stranach vtipne osetrit, aby nabyly hlavne na servru ty nekonecne FIN_WAITs.

Kdyz je napr. client vypnut ze zasuvky, tak pak ukonci server timeoutem
proces.
Jak nekteri radi, ze by pomohl asynchronni server, tomu nerozumim.
Jestlize se vypne client- napr. PC , tak pak chybi to nejdulezitejsi -
totiz proud, aby mohl client jeste z poslednich sil zaslat pres sit
zpravu, ze umira.

> Jeste jsem to dukladne netestoval, ale obavam se, ze v takovem pripade
> read na serveru nevraci EPIPE, ani nedojde k SIG_PIPE. Read zustane
> proste dal cekat, az prijdou nejaka data z (preruseneho) spojeni...
> (v tomhle se mozna mylim, kdyztak me opravte)
>
to je pravda, read ceka

> RESENI: me napadlo jedine - aby server periodicky posilal nejaka data
> typu ACK, na ktera by klient musel odpovedet a ktera by tedy testovala
> spojeni. Pro muj pripad se to ale z ruznych duvodu nehodi.
>
to povazuji za nesmysl, pak musi byt client asynchronni aby rozeznal
co je ACK a co je odpoved na bezny dotaz. Ale to jsem vyrozumnel prave
nechcete, cela komunikace je koncipovana synchronne?

s pozdravem
Jan