Re: Example socket program to send data to a non IBM i device

I have the program in production and its working well except, for the
timeout issue. I have a work around using multiple jobs in the jobq.

I contacted IBM with the timeout issue and they responded with this answer.
-------
There isn't any way of controlling that when establishing a TCP socket
connection. What is happening is that your application initiates a
connect() which has TCP send a SYN packet. If the other end is not
listening on that server, we won't get a SYN ACK back. Because of TCP
re-transmission settings, if we haven't received a response, we will try
again (re-transmit the SYN) in 3 seconds, and then in 6, 12, 24, 48, etc
seconds each time waiting for a SYN ACK response. After 5 attempts if
there is no response, we will give up. I think this would match up with
your 180 seconds (3 minutes approx). Connection retries are hardcoded on
the IBM i, so there isn't any way of changing that sequence. However, if
the application server were to send back a RST packet to our SYN attempt,
then I believe we would immediately stop retransmitting the packet because
we have received a response that the port is not listening/accepting
requests. If the whole system is unavailable, then it might depend on how
the remote network responds to a request to that IP address. If no
response is received however, we will attempt to retransmit the SYN as
above.
----

Has anyone found a work around to the timeout issue. I did put in a RFE to
have the timeout changed to allow us to specify a new value.

Darryl Freinkel



On Wed, Feb 20, 2019 at 5:06 PM a4g atl <a4ginatl2@xxxxxxxxx> wrote:

I used a few of the options but all except the non blocking failed.

Non blocking did the trick.

Thank you all.

Darryl Freinkel.


On Wed, Feb 20, 2019 at 4:29 PM Scott Klement <midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Darryl,

I found the old manuscripts for some of the articles on socket timeouts
that I wrote and stuck them online, here:

http://www.scottklement.com/rpg/socktimeout/

This is just quick & dirty... it may contain broken links to old stuff
thats no longer online, or other references to other articles, and the
formatting is VERY basic... but it should give you what you need about
how to incorporate timeout logic into your programs.

-SK


On 2/20/2019 2:44 PM, Scott Klement wrote:

Hi Darryl,

Those constants are just mnemonics ;-) Changing that won't change
the timeout value, and SO_SNDTIMEO doesn't apply to the standard
socket API, anyway.

There are two ways to do timeouts in socket programming:

1) You can use signals, such as the alarm() API with SIGALRM to
interrupt a socket call after a given time period. This is quick and
dirty, but doesn't work everywhere (some jobs block signals).

2) You can use non-blocking sockets together with the select() API.
(technically you can do this with blocking as well, but its not as
robust.) This is the best way, but its more work.

Unfortunately the articles I wrote about this are no longer online
(when iProDeveloper.com/SystemiNetwork.com was taken down, all of my
articles went with it.) Otherwise I'd give you a link.

-SK


On 2/20/2019 1:15 PM, a4g atl wrote:

Has anyone been able to change the send timeout values? I tried

changing

the SO_SNDTIMEO constant value from 70 to 10, but this has not made a
difference.

I need to get the timeout changed to 3 to 5 seconds.

Darryl Freinkel.


On Wed, Feb 20, 2019 at 9:27 AM a4g atl <a4ginatl2@xxxxxxxxx> wrote:

Scott is correct. We have equipment that may not be online all the

time

and in this instance, the program is waiting for the response.

At this point the "default" timeout is somewhere in the regions of 3
to 5
minutes before dropping back to my code. I am working to reduce this
to 3
seconds, today.

This is a major issue here as we have between 5 and 100 devices and

for

those not responding, it delays the entire process as its a single
threaded
process. 20 devices being offline results in a delay of 60 minutes.

TIA

Darryl


On Tue, Feb 19, 2019 at 1:26 PM Scott Klement
<midrange-l@xxxxxxxxxxxxxxxx>
wrote:

Alan,

I'd like to reply to some of the things in your message, I'll put my
comments inline.

The hanging thing is a new one. Are other people using this socket

server?

It doesn't sound like the socket server is not responding, it sounds

like

you are connecting and then being hung up.

"Socket" is a set of routines that can be used for many different
things... I assume this example is TCP?

It is an extremely frequent issue with TCP that they "hang" when a
firewall is blocking the connection, or when the network connection
gets
broken, etc. TCP is meant to be completely reliable, so the

receiving

side will send acknowledgements of the data received, and the sender
will re-send anything that wasn't acknowledged, basically it'll get
stuck re-sending indefinitely if it gets no response.

For that reason, you should always implement a time out mechanism in

a

TCP application.

Normally socket attempts to make a connection. That connection is
either
accepted or rejected. If there is nothing to connect to it just
returns

an

error.

...but that error can only be received if the network connection is
open
and working. If something is blocking it (a firewall, or something
like
an unplugged cable, power turned off, etc... anything that would
prevent
the error message being sent back) instead of an error, you'll sit

and

wait indefinitely.


If by "socket server" (hate that term) you don't mean a TCP server

but

you mean something else, then my comments above may not apply. It'd
help
me out a lot if you'd be more specific rather than using terms like
"socket server" or "socket client". Say TCP if you mean TCP. If you
can be even more specific (like Telnet, FTP, HTTP, SMTP, PPTP, etc)
then
please do.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L)

mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

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

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com