Re: SOCKET Connect() connects but shouldn't.

I just read your article Scott.  How can you possibly know so much about 
communicatins programming?!?!?  This is really amazing. Most of us AS/400 
people are lucky to write a subfile and here you could probably write an 
operating system all by yourself.

I learned a lot and I'm going to spend some time going through your article and 
tutorial(again) see what else I can learn and understand.  

I promise not to bug you again. At least not for awhile anyway. 

Dave Johnson.

Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx> wrote: > Is there any setting on the 
AS/400 that will allow you to make a failed 
> socket connection to drop faster than whatever the default rate is? I'm 
> thinking that if my program attempts to connect to a socket server and 
> it cannot, or if it does connect and then later cannot send (maybe the 
> connection dropped or something...who knows...) is there some way I 
> could force the connection or send attempt to stop at some predetermined 
> time limit rather than the system default and have the user just sit 
> there and wait and wait and wait until it finally gives up?

In other words, you want to control how quickly the connect() attempt 
times out.

> I was thinking that the socket linger routiines you gave as examples 
> would handle this for me but I wasn't absolutely sure about that.

No, linger affects how long the program waits when you call the close() 
API.  If you enable lingering, your program will halt on the call to 
close() and wait for all of the data you've written to be received by the 
other computer.

Without linger, your program will close() the socket immediately, and 
continue on it's merry way, but the operating system will hang onto the 
data you've written and allow the remote site to read the rest of it in 
the background.


To set a time-out value on the connect() API...  actually, there are two 
ways:

a) Using a non-blocking socket, you can start the connection going by 
calling the connect() API.  Then you can wait on the select() API until 
the socket is writable, or until a timeout period occurs.  If the timeout 
comes first, you can close() the socket and give up.  If the socket is 
writable first, then you can call getsockopt() with SO_ERROR to find out 
whether it succeeded, or whether there was an error.

Here's a sample of doing something similar with the recv() API.  Of 
course, you'll have to modify it to use it with connect():
http://archive.midrange.com/rpg400-l/200112/msg00539.html


b) You can use the sigaction() and alarm() APIs to tell the operating 
system to send you a signal.  If your program receives the signal while 
it's waiting on the connect() API (or any socket API) it'll return -1 
(or at least, that'd be what happens normally!) and errno will be set to 
EINTR.  So you can then call close() to cancel the connection attempt.

I wrote an article about this technique for my newsletter. You can read it 
at the following link (requires a membership on the iSeries Network, 
though a free "Associate" membership will do the trick):
http://www.iseriesnetwork.com/article.cfm?id=51720

Both of those techniques work, and both will work on other APIs such as 
send(), recv(), and accept() as well as connect().  (In fact, that article 
demonstrates all of these.)