RE: Socket program problem

Well,  I have tried everything I can think of and what you guys suggested
and still losing the connection before all data is received by the PC
client.

I am going to explain what is happening in a bit more detail in the hopes I
am doing something wrong.

The iSeries is acting as the Server and it sits and waits for the PC Clients
to connect.
The PC sends a request for a file to the iSeries and then waits for a
response back (Event message).
The iSeries builds the file and sends it back to the PC one record at a time
(in XML format) The building of the file and sending all of the records in
XML format takes about 2 seconds.
While the iSeries is sending the records, the PC client starts receiving the
records in groups (number of records it receives with each receive varies
from 1-5 records at a time) Before the PC receives all the records it
receives a 10053  WSAECONNABORTED and transmission is terminated.

I read somewhere that after sending data I should wait for an ack before
proceeding. Does this mean when the iSeries send a single record it should
wait til the PC receives it and the PC send an ack back to the iSeries, then
the iSeries should send another record etc. etc. ?

In this application when the iSeries receives a request (ie PC wants file x)
The iSeries spawns off a separate job that builds the file and send the data
to the PC. 
The iSeries never acknowledges to the PC that it got the request. It just
builds the file and starts sending records to the PC. When the iSeries
program (spawned program) is done sending the records it ends. 
The PC (client) starts receiving the records and when done receiving the
records it displays them. 

At all 10 remote locations, if the file requested is small (about 10
records) all 10 locations work fine, they receive all data just fine.

But when the file requested is larger (about 20 or so records)
Two of our 10 remote locations never receive all the data They both
consistently get the 10053  WSAECONNABORTED before all records are received.

We were going to re-write the application tonight and write it so that
whenever the PC or the iSeries sends data (even after each individual( they
are going to wait until the other side ack that they received the data and
is waiting for the next

Is this a waste of my time? The programmers here are just guessing at what
it could be, but we are out of ideas except for this rewrite.

New program would
1) iSeries waiting for request
2) PC send req to iSeries for file X, then waits for ack from iSeries
3) iSeries receives request for file x, sends ack to the PC that the request
was received and spawns Job A to build the file and transmit to PC
4) PC get ack from iseries and waits for data
5) iSeries Job A build file and sends record 1 (with X'FF' at end of record)
then waits for ack from PC that the record was received
PC receives record 1 and knows it is complete because of x'FF' and send ack
to the iSeries
6) iSeries receives ack from PC and the two go back and forth til all
records are sent and received.

Is there any chance this might fix my problem?

John   

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, September 08, 2003 5:06 PM
To: Midrange Systems Technical Discussion
Subject: RE: Socket program problem



On Mon, 8 Sep 2003, John Allen wrote:
>
> Would it be abnormal for a PC program to take 2 minutes to read 10,000
> bytes

Depends on the speed of the connection and how busy the line is, I guess.
10000 bytes in 2 minutes is what?  666bps?  About half the speed of a 1200
baud modem!  If the line is VERY busy, I guess that's possible.   Seems
unlikely, though.

I'd say it's more likely that something is wrong with their setup.  Either
the PC program is poorly written, or theres a problem with the networking
between the iSeries and the PC that's causing it to drop packets.

>
> of data? It takes the iSeries .05 (5 hundredths of a second) to send the
> data.
>

How could the iSeries take 0.05 seconds if the PC takes 2 minutes?  Are
you just talking about the time it takes to put the data into the buffer?
(The time it takes for the send() or write() API to complete?)

> I will set it to 240 and see if it makes a difference
> I should be able to see if the amount of data received on the PC at least
> increase from 16 records currently being read before it ends.

Worth a try.

>
> I will also add a X'FF' at the end of the transmission and change the
Client
> to look for it to stop receiving data.
>

If that helps, it'd probably imply that something was written incorrectly
in the application.

> When I said that the PC is waiting for an acknowledgment that data was
ready
> to be retrieved I was talking about Windows Event Message. I did not
realize
> it would receive one for each part of the transmission. So that must not
be
> the problem.

Well, again, it could be if the PC program isn't completely reading all
data from the socket's buffer each time.

>
> I believe (correct me if I am wrong) that the Event message carries with
it
> the number of bytes to be read from the buffer.
>

No, there's no byte count associated with the message.  (At least not if,
as I surmise, he's using the WSAAsyncSelect() API with FD_READ)
If you think about it, it wouldn't make sense to give a number of bytes
since windows event messages are queued, and the potential exists for a
lot of new data to be added to the buffer between the time the message
is added to the queue and the time that recv() is called.

The way I use that API is to use a non-blocking socket to read the data,
and simply read the socket until I get a WSAEWOULDBLOCK error indicating
that I've retrieved everything.

Good Luck!
_______________________________________________
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.