RE: tcp/ip socket slowdown -- MIDRANGE-L

Hi Rick,

    C                   If        Bytesread <= 0
    C                   Call(e)   'SLEEPCL'
    C                   Parm      '000001'      Delay
    C                   Eval      RecvTries += 1

What's this about?! I would definitely assume that this is the problem.When the recv() API returns a number <= 0, there's an error. You need tocheck errno and handle it appropriately.

If the error is EAGAIN, then there's no data to read at the moment. Inwhich case you should use the select() API to wait until there's data.You should NOT simply delay for a second!

I suspect that what's happening is that the system is trying to send youdata very quickly... if it's a 10 megabit connection, it'd be sending yousomething like 100 kilobytes a second, right? (give or take). You havean 8k socket buffer to receive data into. So this is what you do:


a) Read everything that's on the socket (at most, 8k)

b) Try to read again -- this'll happen instantly, because the computer iswaaaaay faster than the network. So recv() will return 0.

c) You sleep for 1 second. During that time, Windows tries to send you100k of information, but since you only have 8k in your buffer, Windowscan only send 8k before stopping.


d) Go back to step (a).

This results in an 8k/second transfer rate, because your program keepsstopping the receive process for 1 second intervals. Actually, that'snot entirely accurate, because it's possible that Windows will get a fewbytes into the buffer in between the recv() and the next recv() call, soyou might not always hit the sleep... based on your benchmarks, I'dguess that it's hitting the 1 second sleep about half of the time.

The fix is easy... get rid of the SLEEPCL and use the select() API towait for data on the socket.


Tell select() that you want to:

a) Wait until 1 second has elapsed.
-- or --
b) Until there's data to read on the socket.

So if there's data to receive, it doesn't sit and wait -- it immediatelyreads it. If there isn't data, it waits and doesn't consume CPU time.That's what the select() API is designed for.

Though, actually, I wouldn't use a 1 second delay time on the select().Since it'll resume processing as soon as there's data, you no longer needto keep checking every second. You can just set the timeout to be 28800seconds or whatever you think a reasonable time to wait would be. I don'tknow if there are long "lulls" in the conversation or not.

OF course, 28800 is a long time to wait for an error. Unless it's normalto have long delays between receiving data (for example, when waiting fora user), I'd set the timeout to something more like 30 seconds. Butthat's neither here nor there... your problem is almost certainly thecall to SLEEPCL.