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!