|
Does the problem happen regardless of which PC you use? Have you tried using
a PC from a location that works correctly?
Albert York
-----Original Message-----
From: John Allen [SMTP:jallen@xxxxxxxxxxx]
Sent: Thursday, September 11, 2003 9:14 AM
To: 'Midrange Systems Technical Discussion'
Subject: 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.
_______________________________________________
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.