Quesetion : Socket API about recv()

Hi~! ALL...

I have a some question about recv() API.

1. client side. (Server is EchoServer)
- socket create.
- connet to server.
- shutdown(fd, 0); // receives disallowed.
- send (); // OK
- recv ();
// this return value is 0. but I think this return value is -1
(error)

After calling shutdown() which parameter 'how' is 0, what is the
return value of recv()?

2. also client side.
- socket create
- connect to server.
- pull out the lan cable.
- recv ();
// why didn't recv() return? I belive that recv() should return
-1(error).
// but the recv() is blocking.
// Is it correct?


Thanks In Advance.

In article <(E-Mail Removed) >,
(E-Mail Removed) (Seunghwan Hong) writes:

>Hi~! ALL...
>
>I have a some question about recv() API.
>
>1. client side. (Server is EchoServer)
> - socket create.
> - connet to server.
> - shutdown(fd, 0); // receives disallowed.
> - send (); // OK
> - recv ();
> // this return value is 0. but I think this return value is -1
>(error)
>
>After calling shutdown() which parameter 'how' is 0, what is the
>return value of recv()?

I've never used shutdown(), but consider that recv() returns zero
if the connection has been closed. Zero sounds like a reasonable
response in your situation. Remember that when recv() returns zero,
it does _not_ mean that no data is ready; it means that the connection
has been closed.

>2. also client side.
> - socket create
> - connect to server.
> - pull out the lan cable.
> - recv ();
> // why didn't recv() return? I belive that recv() should return
>-1(error).
> // but the recv() is blocking.
> // Is it correct?

TCP/IP is a very robust and forgiving protocol. If you plug the
cable back in and some data comes through, recv() will return.
It doesn't throw up its hands if something - including hardware! -
isn't instantly ready. I've had a PPP connection to my ISP go
down while doing a big download; the program patiently waited
while I dialed back in, then continued where it left off.
There is a timeout, but it's quite long - 5 minutes or so.

--
/~\ (E-Mail Removed)lid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

"Charlie Gibbs" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In article <(E-Mail Removed) >,
> (E-Mail Removed) (Seunghwan Hong) writes:
>
> >Hi~! ALL...
> >
> >I have a some question about recv() API.
> >
> >1. client side. (Server is EchoServer)
> > - socket create.
> > - connet to server.
> > - shutdown(fd, 0); // receives disallowed.
> > - send (); // OK
> > - recv ();
> > // this return value is 0. but I think this return value is -1
> >(error)
> >
> >After calling shutdown() which parameter 'how' is 0, what is the
> >return value of recv()?
>
> I've never used shutdown(), but consider that recv() returns zero
> if the connection has been closed. Zero sounds like a reasonable
> response in your situation. Remember that when recv() returns zero,
> it does _not_ mean that no data is ready; it means that the connection
> has been closed.
>
> >2. also client side.
> > - socket create
> > - connect to server.
> > - pull out the lan cable.
> > - recv ();
> > // why didn't recv() return? I belive that recv() should return
> >-1(error).
> > // but the recv() is blocking.
> > // Is it correct?
>
> TCP/IP is a very robust and forgiving protocol. If you plug the
> cable back in and some data comes through, recv() will return.
> It doesn't throw up its hands if something - including hardware! -
> isn't instantly ready. I've had a PPP connection to my ISP go
> down while doing a big download; the program patiently waited
> while I dialed back in, then continued where it left off.
> There is a timeout, but it's quite long - 5 minutes or so.

I don't think receive has any timeout (unless SO_KEEPALIVE is used). Thus if
you do a blocking receive and if the network connection fails ideally the
receive should block forever.

"Pirabhu Raman" <(E-Mail Removed)> wrote in message news:<cgl8km$q7c$(E-Mail Removed)>...
> "Charlie Gibbs" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <(E-Mail Removed) >,
> > (E-Mail Removed) (Seunghwan Hong) writes:
> >
> > >Hi~! ALL...
> > >
> > >I have a some question about recv() API.
> > >
> > >1. client side. (Server is EchoServer)
> > > - socket create.
> > > - connet to server.
> > > - shutdown(fd, 0); // receives disallowed.
> > > - send (); // OK
> > > - recv ();
> > > // this return value is 0. but I think this return value is -1
> > >(error)
> > >
> > >After calling shutdown() which parameter 'how' is 0, what is the
> > >return value of recv()?
> >
> > I've never used shutdown(), but consider that recv() returns zero
> > if the connection has been closed. Zero sounds like a reasonable
> > response in your situation. Remember that when recv() returns zero,
> > it does _not_ mean that no data is ready; it means that the connection
> > has been closed.
> >
> > >2. also client side.
> > > - socket create
> > > - connect to server.
> > > - pull out the lan cable.
> > > - recv ();
> > > // why didn't recv() return? I belive that recv() should return
> > >-1(error).
> > > // but the recv() is blocking.
> > > // Is it correct?
> >
> > TCP/IP is a very robust and forgiving protocol. If you plug the
> > cable back in and some data comes through, recv() will return.
> > It doesn't throw up its hands if something - including hardware! -
> > isn't instantly ready. I've had a PPP connection to my ISP go
> > down while doing a big download; the program patiently waited
> > while I dialed back in, then continued where it left off.
> > There is a timeout, but it's quite long - 5 minutes or so.
>
> I don't think receive has any timeout (unless SO_KEEPALIVE is used). Thus if
> you do a blocking receive and if the network connection fails ideally the
> receive should block forever.

Yes, I think so.
I belive the recv() function should be blocked.
But, WinSock didn't blocked the recv().
When the lan cable is pulled out, recv() of Winsock return -1.

Thanks.

"Pirabhu Raman" <(E-Mail Removed)> wrote in message news:<cgl8km$q7c$(E-Mail Removed)>...
> "Charlie Gibbs" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > In article <(E-Mail Removed) >,
> > (E-Mail Removed) (Seunghwan Hong) writes:
> >
> > >Hi~! ALL...
> > >
> > >I have a some question about recv() API.
> > >
> > >1. client side. (Server is EchoServer)
> > > - socket create.
> > > - connet to server.
> > > - shutdown(fd, 0); // receives disallowed.
> > > - send (); // OK
> > > - recv ();
> > > // this return value is 0. but I think this return value is -1
> > >(error)
> > >
> > >After calling shutdown() which parameter 'how' is 0, what is the
> > >return value of recv()?
> >
> > I've never used shutdown(), but consider that recv() returns zero
> > if the connection has been closed. Zero sounds like a reasonable
> > response in your situation. Remember that when recv() returns zero,
> > it does _not_ mean that no data is ready; it means that the connection
> > has been closed.
> >
> > >2. also client side.
> > > - socket create
> > > - connect to server.
> > > - pull out the lan cable.
> > > - recv ();
> > > // why didn't recv() return? I belive that recv() should return
> > >-1(error).
> > > // but the recv() is blocking.
> > > // Is it correct?
> >
> > TCP/IP is a very robust and forgiving protocol. If you plug the
> > cable back in and some data comes through, recv() will return.
> > It doesn't throw up its hands if something - including hardware! -
> > isn't instantly ready. I've had a PPP connection to my ISP go
> > down while doing a big download; the program patiently waited
> > while I dialed back in, then continued where it left off.
> > There is a timeout, but it's quite long - 5 minutes or so.
>
> I don't think receive has any timeout (unless SO_KEEPALIVE is used). Thus if
> you do a blocking receive and if the network connection fails ideally the
> receive should block forever.

Yes, I think so.
I belive the recv() function should be blocked.
But, WinSock didn't blocked the recv().
When the lan cable is pulled out, recv() of Winsock return -1.

Thanks.

"Seunghwan Hong" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
> "Pirabhu Raman" <(E-Mail Removed)> wrote in message
news:<cgl8km$q7c$(E-Mail Removed)>...
> > "Charlie Gibbs" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > In article <(E-Mail Removed) >,
> > > (E-Mail Removed) (Seunghwan Hong) writes:
> > >
> > > >Hi~! ALL...
> > > >
> > > >I have a some question about recv() API.
> > > >
> > > >1. client side. (Server is EchoServer)
> > > > - socket create.
> > > > - connet to server.
> > > > - shutdown(fd, 0); // receives disallowed.
> > > > - send (); // OK
> > > > - recv ();
> > > > // this return value is 0. but I think this return value is -1
> > > >(error)
> > > >
> > > >After calling shutdown() which parameter 'how' is 0, what is the
> > > >return value of recv()?
> > >
> > > I've never used shutdown(), but consider that recv() returns zero
> > > if the connection has been closed. Zero sounds like a reasonable
> > > response in your situation. Remember that when recv() returns zero,
> > > it does _not_ mean that no data is ready; it means that the connection
> > > has been closed.
> > >
> > > >2. also client side.
> > > > - socket create
> > > > - connect to server.
> > > > - pull out the lan cable.
> > > > - recv ();
> > > > // why didn't recv() return? I belive that recv() should return
> > > >-1(error).
> > > > // but the recv() is blocking.
> > > > // Is it correct?
> > >
> > > TCP/IP is a very robust and forgiving protocol. If you plug the
> > > cable back in and some data comes through, recv() will return.
> > > It doesn't throw up its hands if something - including hardware! -
> > > isn't instantly ready. I've had a PPP connection to my ISP go
> > > down while doing a big download; the program patiently waited
> > > while I dialed back in, then continued where it left off.
> > > There is a timeout, but it's quite long - 5 minutes or so.
> >
> > I don't think receive has any timeout (unless SO_KEEPALIVE is used).
Thus if
> > you do a blocking receive and if the network connection fails ideally
the
> > receive should block forever.
>
> Yes, I think so.
> I belive the recv() function should be blocked.
> But, WinSock didn't blocked the recv().
> When the lan cable is pulled out, recv() of Winsock return -1.

Hmm...I haven't actually used it. This should happen only if there are some
keep alive packets exchanged. Can you use some software like ethereal to see
what packets are being sent on the network when your socket is blocked on
receive?