Don't know if this is related, but I also am having trouble with recv().
Since I don't know when I've received everything that will be sent (from
telephone switch equipment), if I don't find the expected string in the
buffer, I save what I've received so far and call recv() again. This
seems to work to get additional data when I'm trying to check results
too soon, but I suspect when there's nothing more to be sent (how would
I know?), and I call recv() again, control does not return to my RPG
program.
Has recv() timed out? I have to crash the job, which leaves a
connection to the switch open and messes to clean up.
I haven't done anything fancy with recv(). The line that locks up is:
rc = recv(sock: %addr(recbuf):3000:0);
I send the request to the switch with "send(sock: %addr(request):
reqlen:0)", and then execute a dou loop to interpret the response from
the switch:
Dou done;
[wait a bit]
Recbuf = *blanks;
rc = recv(sock: %addr(recbuf):3000:0);
[translate recbuf to EBCDIC and scan for expected prompt
string]
[If found, leave do loop - else, repeat loop up to a
reasonable number of times]
Enddo;
Debug confirms that it hangs on recv(). Works well so long as the
expected prompt is returned, but I can't process the "not found"
condition if I don't know that there isn't more to receive...
Suggestions welcome!
Michael
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, February 23, 2011 3:50 PM
To: RPG programming on the IBM i / System i
Subject: Re: Socket Recv Question
Have you disabled Nagle's algorithm? That may be throwing off your
benchmarks.
On 2/23/2011 2:31 PM, Zachary Johnson wrote:
Hi Scott, thanks for the reply. Yes, using SOCK_STREAM. I still
think it's odd though that the short request would take longer to
arrive on the socket than the large request. It's driving me up the
wall that I have no other explanation other than "that's how it
works". Thanks again for the response.
midrange.com
