RE: Test device before connect()

Scott and Patrick,

Thanks so much for pointing me in the right direction.


I have other socket programs (direct print) that I will look at too.


Thanks again,


Craig



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Scott Klement
Sent: Friday, October 24, 2008 6:36 PM
To: RPG programming on the AS400 / iSeries
Subject: Re: Test device before connect()

Craig Jacobsen wrote:

When it drops, the connect() hangs for 3 to 5 minutes trying to make a
connection.
(I would like that to be a few seconds, but there are no time out values
that I can see.)

Here's an article that I wrote about timeouts with sockets. It
describes two ways to do a timeout, and has sample code for the connect API:
http://systeminetwork.com/article/timeouts-sockets-0


Further, I would add that if you want to write robust TCP apps -- ones
that can survive a network that's having trouble -- then you need to be
using non-blocking sockets throughout your application.

Non-blocking assures that your application can NEVER get stuck forever
waiting for the network. And in a robust application, that's a very
important thing to do.

You were lucky in your instance -- you got stuck on the connect() API,
which is relatively kind in that it times out after a number of minutes.
Had you had the network error during a send() or recv() API, you
might've gotten hung up permanently with no timeouts at all.

Use non-blocking with select() for everything you do. Write yourself a
library of socket routines and put them in a service program and have
them do all of the work for you, including the non-blocking and select()
code.

In THAT environment, you'll never get hung up permanently, and you'll
have complete control over how long you wait for a time out.