RE: Connect timeout value in SockUtilR4

Scott,

Thanks again for the help.

I did not realise that I could turn blocking on and off once a socket
session was established.
This is much better for me, as I only want the timings to apply when
connect() is processed, but want blocking for everything downstream of that.
Reasons are that:
a. The server we are talking to is our 'server' - a program we wrote for a
PC, & we control everything that happens
b. Some of the timings at the server end are variable & can't be estimated
at  the client end (Users entering data etc & going for coffee) etc.

There's a lot more in these sockets server programs than I realised ...  :-)

Regards

Ian Patterson



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx]On Behalf Of Scott Klement
Sent: 14 April 2004 23:37
To: Midrange Systems Technical Discussion
Subject: Re: Connect timeout value in SockUtilR4



Hi Ian,

> Does anyone know which (if any) parameter controls the timeout value for
the
> connect() function in Scott's sockutilr4 server program ?
> It currently waits for about a minute (I've not exactly timed it) before
> returning an error that the remote host is not answering.
>
> I want to get it down to about 10 secs.

Timeouts in sockets applications are controlled by using the select() API.
In the case of connect(), you do the following:

   1) Call socket() API
   2) Use fcntl() to make the socket non-blocking
   3) Call connect().  Usually you'll get an error that tells you that
        the connection is "in progress" (EINPROGRESS).  Make sure that you
        check errno so that any "real" errors are detected.
   4) call select() to wait until the connection is WRITEABLE.  (that's
        the weird thing about connect, the socket has to be writeable)
        You can set your timeout on the select() call.
   5) If a timeout occurred on the select() call, make sure you call
        close() so that the connection attempt is aborted and the
        resources are returned to the system.
   6) If a timeout did not occur, I usually call connect() again to see
        if the connection was successful.  If so, connect() will return
        a "already connected" (EISCONN) error.

If you'd like to see a working example, take a look at the http_conn()
subprocedure of HTTPAPI.   (In fact, you could probably just call that
routine instead of the one in SOCKUTILR4)

http://www.scottklement.com/httpapi/

After you've connected, you can put the socket back into blocking mode if
you're worried about it affecting the rest of the application -- though a
better idea is to simply call select() before you do any recv() or send()
calls.  That way you can have timeouts in all aspects of the program, and
never have the program "get stuck" if anything goes wrong.

_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.