Re: Socket Listener Delay Issue

I can't see how TCP_NODELAY (also called "Nagle's Algorithm) could cause the symptoms you're seeing...

The basic idea here is that TCP will wait a very small amount (a fraction of a second) if there isn't enough data to make up a full packet. For example, if a program is sitting in a loop, sending 100 bytes at a time, but looping so that the total data sent might be kilobytes or more... the idea is that because you're in a loop, your data will be combined, allowing up to the maximum packet size (usually around 1500 bytes including the headers) to be sent at once.

Without TCP_NODELAY, the aforementioned loop would send 100 bytes in each packet (and since each packet has a minimum of 40 bytes of header information, that would seem like a real waste to spend 40% or more of your transmission bandwidth on headers.)

There are a few cases where TCP_NODELAY is useful -- the most obvious being Telnet in the way it's implemented for Unix systems. Here each time you press a keypress, it needs to be sent to the server, and you need to wait for it to be echoed back from the server. (This is different from 5250 where a whole screen is submitted at once.) In this case, you're often sending one byte (plus headers) at a time, and it's more important that this byte be echoed back ASAP than it is to optimize bandwidth (since Telnet is usually pretty low volume, anyway).

But, since your symptoms involve 20+ minutes of delay (not a fraction of a second) and since it happens during a connection (not during TCP transmission) TCP_NODELAY can't possibly be the problem.


On 8/8/2013 7:34 PM, Rich Marion wrote:

I haven't really tried. I have not heard of LoadRunner. I will research
and try.

Seeing your question about TCP_NODELAY made me hopeful. I spent a couple
hours researching what it did.
My understanding of the TCP_NODELAY option is that it affects outgoing
packets. Telling the system to not buffer outgoing information and to send
each packet whether or not is it full. Basically, send smaller sized
packets, immediately. My issue is after the packets are received, they sit
in the buffer waiting to the listener program to get them, but the listener
does not know they exist. I am not sure if this will work, I configured
the TEST system to turn this option on and am currently testing it.

Also the default timeout prior to sending a packet is 200ms. Turn On
TCP_NODELAY and it drops to 0ms (or close to it). The delays I am
experiencing is over 10 seconds.

Thanks for your help, I am trying it out.
Rich



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of Nathan Andelin
Sent: Thursday, August 08, 2013 12:59 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: Re: Socket Listener Delay Issue

I have encountered a little intermittent problem with a program that
is monitoring a port for any incoming connections.

Can you duplicate the problem by using a stress tester such as HP
LoadRunner?

We don't have enough information to say whether or not your socket server
might simply not be getting system resources it needs in a timely manner,
perhaps a condition due to contention with other workloads. You could reduce
the timeslice value of other workloads (interactive, batch) to some fairly
low value, say 20 milliseconds (modify the CLASS associated with
Subsystems).

I'm also curious what your TCP_NODELAY setting might be?
See setsockopt()--Set Socket Options.

-Nathan.

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6562 - Release Date: 08/08/13


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.3392 / Virus Database: 3209/6562 - Release Date: 08/08/13