× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We are using TCP and I am not sure what the buffer would have to do with it,
I was under the impression that Buffer size could be most anything.
How could the packets get out of sequence?

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Chris Bipes
Sent: Monday, September 08, 2003 12:01 PM
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.