Re: Socket program problem -- MIDRANGE-L


On Mon, 8 Sep 2003, John Allen wrote:
>
> The PC User can request a database file, the PC Client sends a request to
> the iSeries, the iSeries creates the file and sends the records back to the
> PC in (XML format) The PC reads the XML data and displays the data on the
> PC. Each XML record sent to the PC has a CRLF appended to the end of the
> record by the iSeries program (but I do not see anywhere in the PC program
> that checks for the CRLF so I am not sure why it does it).
>

XML normally has a CRLF at the end of each line of text.  Without that
CRLF, it would all display as one long "record."   It probably doesn't
matter to the program that reads the file, but it's convienient for
humans.


> The application works well on most of our locations (each location has their
> own iSeries), but there are a couple of locations where it does not work. At
> the locations where it does not work - if the user requests a small file (4
> or 5) records it works fine, if the user requests the same file but it has
> 16+ records then the PC client does not receive all the data and the PC
> program gets error -10053 WSAECONNABORTED when trying to get the next bit of
> data.  Each XML record transmitted from the iSeries to the PC is aprox 350
> bytes in length.  I added a trace file to the iSeries program and it always
> sends the complete file.

Interesting.  Are you tampering with the SO_LINGER value somewhere?
Are you using non-blocking sockets?

> When I debug the PC program I see that each time it receives data it
> receives a different number of bytes (not sure why this is) but it works
> ok until it eventually tries to get the next bit of data and receives
> the error mentioned above.

Do you mean that the server writes (for example) 2000 bytes to the socket,
and the PC only reads (for example) 1300?   That's normal with TCP.   TCP
is not a "record-based" protocol, but rather is a stream based protocol.
The bytes that are written in one end will eventually be read on the other
end, in the same order, without corruption.   But, it's not fixed-length
records -- the data is sent as quickly as possible from one end to the
other, and when you read, you get whichever bytes are available.

If it can get get 1300 of your 2000 bytes there quicker than the whole
amount, you'll only read 1300.   Then, the next read (or group of reads)
should get the remaining 700.

> I know this is not enough information for someone to give me an answer as to
> what the problem is, my question is where do I start looking for the
> problem? Not knowing where to look, I added a delay in the iSeries program
> that sends the data to the Socket to wait one minute before ending and
> closing the socket (I thought maybe it was closing the socket before the PC
> had finished reading the data) but like I said I am new at this and was just
> guessing.

Did the delay make a difference?

The way that I go about troubleshooting these things is by using a telnet
client to separately test the server app and then the client app.  Just
telnet to the server, and type the data that the server program is
expecting.  See if you get the correct data back, or if you get cut off,
etc.   That'll tell you if the problem is on the server.

If not, test the client.  You'll need to use a proxy to connect a telnet
client to your client program, as described here:
   http://www.scottklement.com/rpg/socktut/x1085.html

>
> When I request the exact same file (as one of the locations that is
> failing), the application works fine no matter how many records.
>

Is this referring to after the delay is inserted?   If so, you may
have something wrong with the SO_LINGER settings you're using.
Otherwise, what are you talking about?  When does it fail from those
locations?  When does it succeed?

Or, is this talking about one of the locations that DOES work?