Re: Socket Time-Out Issue

mgarton@xxxxxxxxxxxxxxx wrote:

From your previous email, I can't rely on the return code from the send()
to recognize the socket was closed by the client.

Each socket has a send and receive buffer. If the connection is dead, but there's still data in the receive buffer, the recv() API will not return an error, it'll just give you the data in the buffer. Eventually, when you've emptied the buffer, it'll give you the error message.

Likewise, when sending data, the data is first written to the buffer. You won't get an error immediately (even if the connection is dead) because the system just writes the data into the buffer, and doesn't know (yet) that the connection is dead.

The typical solution to this type of problem is to have each side send a message. For example, after the server is done processing, it sends back a message to the client saying "Processing done" (probably with some sort of a message id code, so it'd be more like "250 Processing Complete"). Then, the client either responds with "acknowledged" or something like that to tell the server that it got the message saying that the transaction is complete.

Because of this extra message exchange after the processing is done, both sides know that the other one has completed the process.

Though, I'd also suspect that the client shouldn't have it's timeout set so low. If 45 seconds is a possible processing time, then I'd want the timeout to be a minimum of 90 seconds -- probably even higher. Timeouts should be designed so that they're rather extreme -- the number should be so high that you KNOW it can't possibly still be processing!

But, any time you REALLY want to make sure something was done successfully, use a system of "acknowledgements" if you receive a message stating that something was acknowledged, you know the other side got it.

The only thing I know to

do is check to see if it has been less than 40 seconds since I received the
message from the client before I send a response.

Mark Garton

***************************************
This message is protected by the Electronic Communications Privacy Act, 18
USCS § 2510 et seq., and may not be used, copied or forwarded without the
consent of the named recipient(s). The information contained in this
message is confidential, is intended only for the use of the individual or
entity named. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, distribution or copying of
this communication is strictly prohibited. If you have received this
communication in error, please notify me immediately at 417-829-5768.

message: 2
date: Tue, 10 Jun 2008 12:29:08 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: Socket Time-out Issues

Hi Mark,

By "negative response code" I assume you mean that the recv() API would
return -1, right? (Normally I hear the term "negative response code" in
conjunction with IBM technologies like APPC or 5250, not with TCP/IP.)

It's true that sometimes recv() will return -1 if an error occurs.
However, you can't rely on this always being the case -- especially over
the Internet.

When the Java side times out and closes the connection, a TCP/IP packet
containing the FIN flag (and probably also the RST flag) is sent from
the Java program to your RPG program, and this is what triggers the
recv() API to return -1. But... what if that packet never arrives?
What if a firewall blocks it? Or a router gets unplugged, and therefore
the packet can't be sent? Or your Internet connection goes down? Or
someone cuts the network cable?

The point is -- these messages that demonstrate errors are handy, but
you can never rely on them. Your recv() API in your RPG program has no
100% safe way to tell the difference between "nothing was sent", vs
"connection is dead".

For that reason, you should ALWAYS implement timeouts on your sockets.
Based on your business rules, determine how long it's acceptable to wait
-- double that -- and if nothing is received in that time, assume that
the connection is dead and start over.

Here's a link to an article I wrote that describes how to do timeouts on
sockets in ILE RPG:
http://systeminetwork.com/article/timeouts-sockets-0

mgarton@xxxxxxxxxxxxxxx wrote:

I have socket client written in Java that sends a message to a socket
server running on the iSeries written in RPG. The socket server is the
spawning socket server based on Scott Klements code. I am having a
problem where the client times out but the server doesn't realize it.

The

client sends a message and times out after 40 seconds if it doesn't

receive

a response. The server receives a message, gets data, and sends a
response. Usually it only take a second or two. On the send of the
response, from the server, I check the response code. If the response

code

is negative, I assume the client didn't get the response and back out

the

change. The java developer assures me that once the timeout is

reached,

the socket connection is ended by the client. I would expect to get a
negative response code on the send from the server, but that is not

always

the case. This week we had some system issues causing the server to

send

responses two or three minutes later. I would have expected the pipe

to

have been broken in that amount of time.

Am I wrong to expect a negative response code on the send from the

server?

Is there anything that I can tweak so the server recognizes the pipe is
broken by the client so that it will get a negative response code?

Thanks,
Mark Garton