Glynn Clements wrote:
>
> Shen Hui wrote:
>
> > I want to write a server program. Several clients can
> > connect to it at the same time(using socket() ,SOCKET_STREAM
> > and SOCKET_DGRAM).
> >
> > Now here is a problem. If some clients abort abmormally,
> > for example, by press
> > "^C" or killed by user, clients can not tell the server to
> > reclaim those sockets. In this circumstance, I want the
> > server know this and then close those sockets that do not
> > connect with the clients any more.
> >
> > How can I know the status of the sockets such as "weather
> > they are connected or broken" ?
>
> For TCP (SOCK_STREAM), the server will be notified by the kernel when
> the connection is closed (e.g. by killing the client).
>
> However, this won't account for the situation where the client system
> crashes while the server is waiting on input. To deal with this, use
> something similar to:
>
> int one = 1;
> setsockopt(fd, SOL_SOCKET, SO_KEEPALIVE, &one, sizeof(one));
>
> at the server end, where `fd' is the descriptor for the socket.
>
> For UDP (SOCK_DGRAM), there is no such thing as a connection. The
> server end will have a single socket which receives all packets from
> all clients.
>
> If the server implements some notion of a `connection' internally,
> i.e. resources are allocated upon receipt of the initial packet, and
> retained until the client sends some kind of termination request, then
> you will need to implement some sort of keepalive timer.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>
there's been an ongoing discussion on the freebsd-hackers list (I think) about
these hanging sockets, which on a unix system can be induced by cutting
your wire, but are the default for M$ clients. (Winsock). The bottom
line is that M$ has twisted the RFCs, and leaves Unix servers
hanging in a FIN_WAIT_2 state, whilst the M$ client wanders away.
Some cynical types call this a DoS attack against Unix servers by
M$. The debate is whether to break the RFC's and timeout these sockets,
or to stay RFC compliant and put up with sockets that are hung "forever".
WIndoze NT servers, of course, implement a non-RFC-compliant hack to
accommodate its "friendly" clients.
This exhausts my knowlege of this subject, alas, but wanted to suggest
the issue as a possible source of these sockets that look like
the user just walked off. Question, then, is does Linux implement
the hack (an 11 minute timeout?) to clear these turkeys out?
Dave
--
Sigmund's out to lunch. Would Zippy do?
