|
midrange.com
I was think more along the lines of a single end-of-transmission (EOT)
character. Anything that is not valid data (such as X'00' or X'FF') would
do.
However, when I read your earlier email I missed the part about the 1 minute
delay before closing. That should be enough time for the data to make it to
your PC. You might want to double check the program on the AS/400 to make
sure it is the latest version. You could also try putting the AS/400 program
in debug to make sure it is sending everything correctly.
Albert York
-----Original Message-----
From: John Allen [SMTP:jallen@xxxxxxxxxxx]
Sent: Monday, September 08, 2003 12:58 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem
I thought about this, because it is the way I expected the program
to be
written.
But then I found that I could send 2,000 bytes of data from the
iSeries and
the PC receives it in pieces. PC might receive the first 1990 bytes
then the
next receive would get the 10 bytes.
If I end the transmission with "NO MORE DATA" The last receive on
the PC
might be "MORE DATA" (the "NO" might be included in the first
receive the PC
did.
If I use this method I guess I would have to buffer all the received
data on
the PC and keep checking for NO MORE DATA then once it is received
process
the buffered data?
Or am I confused?
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of York, Albert
Sent: Monday, September 08, 2003 12:30 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem
I have seen this problem before. The solution that I use is that I
have the
requesting machine (in this case the PC) send an acknowledgement of
some
sort to indicate that it has received all of the data before the
AS/400
closes the socket. Or you can have the AS/400 leave the socket open
until it
has been closed by the PC (or until a certain timeout limit has been
reached).
Albert York
-----Original Message-----
From: Chris Bipes [SMTP:chris.bipes@xxxxxxxxxxxxxxx]
Sent: Monday, September 08, 2003 10:01 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Socket program problem
Look at your TCP Buffers Sizes one the individual machines.
Also
look at
the network configurations. Are there routers / fire walls
between
the
AS400 and the PC on some on the networks? Can you see any
patters
in the
network layout or TCP Buffer sizes? It sounds like the
packets are
arriving
out of sequence and the close is arriving before all the
data is
processed
by the PC. Is this UDP or TCP connection?
-----Original Message-----
From: John Allen
It is a socket program that allows data to be transferred
from the
iSeries
(Server) to the PC (Client).
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).
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. 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.
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.
When I request the exact same file (as one of the locations
that is
failing), the application works fine no matter how many
records.
Each remote location has there own iSeries and only one user
is
using the
application at a time.
_______________________________________________
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.
