Rick Jones wrote:

> Does the setting of the size of the socket buffer really affect the
> speed at which a lost peer is noticed? I could see where it would
> affect how long it would be before your application filled the socket
> buffer, but that isn't really the same thing right?

The behaviour seems to be different in different cases. If the the client
the connection breaks because software-hangs etc. The error is given right
away. However if the connection is lost because the network is down such as
in the case that I cut the cable etc. then it does seem that if I use for
instance 4k buffer size and keep sending pakcets it takes very long to get
anykind of notification that the connection is lost.

> Are you interpreting an EAGAIN or EWOULDBLOCK (which I believe you
> would get when the socket buffer filled) as meaning the remote was
> toast?

I'm hoping to get either one of those messages, but basically any error
would do. Also because of serious threading the errno is sometimes changed
before I have time to read it..

>
> Seems to me that at the time the remote system dissapears of the face
> of the net, there starts something of a race - a race between the TCP
> stack's retransmission limits for the first segment sent after the
> remote goes poof, and how long it is before your application fills the
> local send socket buffer.

This is what I suspect. The question is wheater or not I can do anything
about it?

- Teemu

============================
problems with windows: reboot,
problems with unix: be root.
============================