TCP Socket Using connect in Non Blocking - Results in errors using recv()

TCP Socket Using connect in Non Blocking - Results in errors using recv()

Post by Ken » Fri, 25 Apr 2003 02:36:40



The following is part of a client application running on a Solaris 8
platform.

To enable a timeout to be set when using TCP Sockets connect()

I have first set the socket to non-blocking using getsockopt() and
fcntl()
I then connect(), in case of an EINPROGRESS error I call select() with
a timeout.

On succesfully completing the connection I then use fcntl() to return
the flags to - setting the socket to blocking.

I subsequently use a listening thread which repeatedly calls recv()
the flags in recv() are set to 0 so I expect recv() to work in
blocking mode.

I have tested this against two seperate server applications
1) A Message Router (server) running on a PC running Windows NT
(server uses CAsyncSocket). Everything seems to work OK. Messages are
received at the client and recv() blocks until the next message is
available.
2) A Messsage Router (Server) running on a LynxOS  box. In this case I
experience problems at the Listener (client) the recv() does not
appear to block and continuously returns -1, trapping the errno =
EINVAL (appears to correspond to MSG_OOB flag set and socket still non
blocking. In this case I'm lost for the cause of the problem.

a)Can I change the flags for a socket after connection.
b)Is it possible that the Router (server) is
disconnecting/reconnecting the socket
c)Should recv() block if the flags are set to zero regardless of the
flags set for the socket

If you can help

 
 
 

TCP Socket Using connect in Non Blocking - Results in errors using recv()

Post by Barry Margoli » Fri, 25 Apr 2003 03:06:32




>On succesfully completing the connection I then use fcntl() to return
>the flags to - setting the socket to blocking.

>I subsequently use a listening thread which repeatedly calls recv()
>the flags in recv() are set to 0 so I expect recv() to work in
>blocking mode.

That's a correct expectation.

Quote:>I have tested this against two seperate server applications
>1) A Message Router (server) running on a PC running Windows NT
>(server uses CAsyncSocket). Everything seems to work OK. Messages are
>received at the client and recv() blocks until the next message is
>available.
>2) A Messsage Router (Server) running on a LynxOS  box. In this case I
>experience problems at the Listener (client) the recv() does not
>appear to block and continuously returns -1, trapping the errno =
>EINVAL (appears to correspond to MSG_OOB flag set and socket still non
>blocking. In this case I'm lost for the cause of the problem.

If there's a problem with the socket, it's correct for recv() to return
immediately.  I'm not sure what would cause it to return EINVAL.  Maybe
you've specified a flag that's not supported for that type of socket.

Earlier you said that the flags you supply to recv() are 0; so how can
MSG_OOB flag be set?

Quote:>a)Can I change the flags for a socket after connection.

Yes, you can change between blocking and non-blocking mode.

Quote:>b)Is it possible that the Router (server) is
>disconnecting/reconnecting the socket

Possibly, although in this case recv() should return 0 to indicate EOF if
the connection was closed normally, or ECONNRESET if the server aborted the
connection.

Quote:>c)Should recv() block if the flags are set to zero regardless of the
>flags set for the socket

No.  If the socket is in non-blocking mode, it never blocks.  If the socket
is in blocking mode, it blocks unless you've set the MSG_DONTWAIT flag in
the recv() call.

--

Genuity Managed Services, a Level(3) Company, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.