|
midrange.com
I would try both things. It would at least give you some additional
information to narrow down the problem.
Albert York
-----Original Message-----
From: John Allen [SMTP:jallen@xxxxxxxxxxx]
Sent: Thursday, September 11, 2003 11:00 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem
The remote locations are in different states, so I can't have the
working
and non-working locations swap PC's But I could have them try
another PC at
the same location.
I could have them try their PC and access the iSeries at my location
to see
if it makes a difference?
I will try these two.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert
Sent: Thursday, September 11, 2003 11:43 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem
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.
_______________________________________________
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-2024 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.
