On Wed, 30 Mar 2005, Brian Ford wrote:
On Tue, 29 Mar 2005, Peter A. Castro wrote:
On Tue, 29 Mar 2005, Brian Ford wrote:
If you are doing a normal blocking recv without MSG_PEEK, any return of 0
should mean a closed connection AFAIK.
Unfortunately that's not true for all implementation. It's lega
On Mar 30 10:18, Brian Ford wrote:
> On Tue, 29 Mar 2005, Peter A. Castro wrote:
>
> > On Tue, 29 Mar 2005, Brian Ford wrote:
> >
> > > If you are doing a normal blocking recv without MSG_PEEK, any return of 0
> > > should mean a closed connection AFAIK.
> >
> > Unfortunately that's not true for a
On Tue, 29 Mar 2005, Peter A. Castro wrote:
> On Tue, 29 Mar 2005, Brian Ford wrote:
>
> > If you are doing a normal blocking recv without MSG_PEEK, any return of 0
> > should mean a closed connection AFAIK.
>
> Unfortunately that's not true for all implementation. It's legal for a
> zero length
ome reason.
Thanks
Peter A. Stephens
[EMAIL PROTECTED]
-Original Message-
From: Brian Ford [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 29, 2005 11:36 AM
To: Peter Stephens
Cc: cygwin@cygwin.com
Subject: RE: recv and errno during a connection reset/closed by peer
On Mon, 28 Mar 2
On Tue, 29 Mar 2005, Peter Stephens wrote:
Peter,
Hi Peter :)
I have thought about your suggestion and it makes a lot of sense. If I
understand correctly this is what you are thinking about:
Yes, this is pretty similar to how I've solve this before. It's a good
compromise for an (arguably) imperf
On Tue, 29 Mar 2005, Brian Ford wrote:
On Mon, 28 Mar 2005, Peter Stephens wrote:
FYI - I tried setting the SO_LINGER and the SO_RCVTIMEO on Linux and on
Cygwin (see code below). It makes sense to me that if the timeout has been
exceeded then the recv(..., MSG_PEEK) should do something. On Cygwin
On Tue, 29 Mar 2005, Brian Ford wrote:
On Mon, 28 Mar 2005, Peter A. Castro wrote:
As someone who's seen this behaviour on several platforms, it can happen.
I've had to deal with this little annoyance in other products by having a
retry counter loop. So many consecutive recv()s of 0 length constit
On Mon, 28 Mar 2005, Peter Stephens wrote:
> FYI - I tried setting the SO_LINGER and the SO_RCVTIMEO on Linux and on
> Cygwin (see code below). It makes sense to me that if the timeout has been
> exceeded then the recv(..., MSG_PEEK) should do something. On Cygwin it
> doesn't do anything.
I do
On Tue, 29 Mar 2005, Peter Stephens wrote:
> I have thought about your suggestion and it makes a lot of sense.
>
> It seems like your suggestion would be very portable. A good suggestion and
> the most likely route for me at this point.
Not to me. Maybe I'm missing something, but it seems you a
On Mon, 28 Mar 2005, Peter A. Castro wrote:
> As someone who's seen this behaviour on several platforms, it can happen.
> I've had to deal with this little annoyance in other products by having a
> retry counter loop. So many consecutive recv()s of 0 length constitues a
> closed connection. Some
On Mon, 28 Mar 2005, Peter Stephens wrote:
> Brian
>
> Are you saying that there is no way to distinguish a dropped connection from
> a MSG_PEEK with no data to retrieve?
AFAIK, yes. Why are you using this MSG_PEEK method?
Why not just do a poll and look for POLLHUP
(http://www.opengroup.org/on
Peter,
I have thought about your suggestion and it makes a lot of sense. If I
understand correctly this is what you are thinking about:
int I = 0;
<< another new line
do{
ret_val = recv(afd, buf, MAX_BUF, MSG_PEEK);
if(0 > ret_val)
err(" >>> ERRNO");
else if(0 == ret_
MSDN website article
http://support.microsoft.com/default.aspx?scid=kb;en-us;181610.
Peter A. Stephens
[EMAIL PROTECTED]
-Original Message-
From: Peter A. Castro [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 7:02 PM
To: Peter Stephens
Cc: cygwin@cygwin.com
Subject: RE: recv and e
0';
printf("(%i) \t> %s", ret_val, buf);
}
usleep(250);
done = handle_it(buf);
}while(!done);
printf("Completed\n");
return 0;
}
-Original Message-
From: Peter A. Castro [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 7
so it's not all that old.
Peter A. Stephens
[EMAIL PROTECTED]
-Original Message-
From: Brian Ford [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 11:37 AM
To: Peter Stephens
Cc: cygwin@cygwin.com
Subject: RE: recv and errno during a connection reset/closed by peer
On Fri, 25 Mar
:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 11:37 AM
To: Peter Stephens
Cc: cygwin@cygwin.com
Subject: RE: recv and errno during a connection reset/closed by peer
On Fri, 25 Mar 2005, Peter Stephens wrote:
> I boiled this down to nothing(see below). I must be missing something
> basic
On Fri, 25 Mar 2005, Peter Stephens wrote:
> I boiled this down to nothing(see below). I must be missing something
> basic.
Yup.
> I tried the suggestions made so far and it never gets to:
>
> printf(" >>> ERRNO %i\n", errno);
>
> I would expect that on a disconnect (I use putty in telnet
I boiled this down to nothing(see below). I must be missing something
basic. I tried the suggestions made so far and it never gets to:
printf(" >>> ERRNO %i\n", errno);
I would expect that on a disconnect (I use putty in telnet or raw mode) it
would return -1 whether it is doing MSG_PEE
On Thu, 24 Mar 2005, Brian Dessent wrote:
> Peter Stephens wrote:
>
> > When in non-blocking mode I thought I would be able to get a return
> > from recv of '-1' and then check errno, but it never seems to be
> > anything but '11', or EAGAIN. This seems to be true whether I
> > MSG_PEEK or not.
>
Peter,
This works for me:
/* Detect dead connections */
int keepalive = 1 ;
r = setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE,
(char *)&keepalive,
sizeof(keepalive)) ;
recv() will now return ECONNABORTED when the host
disconnects.
Best regards,
Joris
--
Peter Stephens wrote:
> When in non-blocking mode I thought I would be able to get a return from
> recv of '-1' and then check errno, but it never seems to be anything but
> '11', or EAGAIN. This seems to be true whether I MSG_PEEK or not.
>
> I have included my code below. The intention is tha
I am writing a program to handle messages on a TCP/CONNECTION based setup.
I have verified that I can receive the messages I want, both blocking and
non-blocking. I want to be in non-blocking mode.
When in blocking mode I can detect a loss of the connection simply by
waiting for a return of '0' f
22 matches
Mail list logo
