Very Computer

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

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.