× 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.



Linger is set to 2 minutes. What is this linger value used for? When would I
want to increase or decrease the value? 

It is using blocking sockets

Yes, when the iSeries sends 1,400 bytes and the PC first received 900 bytes,
the next receive on the PC gets the remaining 500 bytes plus some (because
by the time the PC does another receive the iSeries has sent more data)
I am never missing data in the middle of a transmission. I am always missing
data at the end. The PC program gets the error message and stops receiving. 
(only on the larger files)

When I added the delay of 1 minute after the last transmission from the
iSeries (before shutting down and closing the socket) it did not make any
difference.

The program fails at two locations (A & B) every time the file being
transmitted from the iSeries is larger then a few records (it works at those
locations if the database file is only a few records). It never fails at my
other locations or my location. I thought it might be the data in the
failing locations database, so I had them send me their database file from
their iSeries. I used their database at my location and it worked fine. So
from this I can assume it is not the data in the data base file containing
weird characters (like LF CR or characters that XML does not like & > <)

Question if the PC is running slower then the iSeries, and the iSeries
transmits 10,000 bytes, if the iSeries then ends and closes the socket
before the PC has had time to receive all 10,000 bytes, can the PC continue
to do receives and get the remaining bytes? Or will the receive return an
error and the remaining data is lost (which sounds like my problem)

Keep in mind I am not much of a C++ programmer either..

If we are not transmitting some type of "end of data" value to the PC Client
to let it know there is no more data, How would the PC app no there is no
more data other then the socket is closed by the iSeries.

The PC programmer working on this says that the PC program waits for some
type of acknowledgment that there is data to receive it then does a receive
to get the data, then waits for another acknowledgment that there is data to
receive. Does this sound normal?
It seems to me if this is true and the iSeries send 10,000 bytes in 5
transmissions and the PC is receiving less then 2,000 bytes per receive that
it will not get all the data because it will only get 5 acknowledgments that
there is data to receive.
It seems to me the PC should continually do receives until it gets a message
back that the socket is closed?

I may be in over my head on this one.

But I thank you all for your patience
 
   

 


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Monday, September 08, 2003 1:39 PM
To: Midrange Systems Technical Discussion
Subject: Re: Socket program problem



On Mon, 8 Sep 2003, John Allen wrote:
>
> 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).
>

XML normally has a CRLF at the end of each line of text.  Without that
CRLF, it would all display as one long "record."   It probably doesn't
matter to the program that reads the file, but it's convienient for
humans.


> 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.

Interesting.  Are you tampering with the SO_LINGER value somewhere?
Are you using non-blocking sockets?

> 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.

Do you mean that the server writes (for example) 2000 bytes to the socket,
and the PC only reads (for example) 1300?   That's normal with TCP.   TCP
is not a "record-based" protocol, but rather is a stream based protocol.
The bytes that are written in one end will eventually be read on the other
end, in the same order, without corruption.   But, it's not fixed-length
records -- the data is sent as quickly as possible from one end to the
other, and when you read, you get whichever bytes are available.

If it can get get 1300 of your 2000 bytes there quicker than the whole
amount, you'll only read 1300.   Then, the next read (or group of reads)
should get the remaining 700.

> 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.

Did the delay make a difference?

The way that I go about troubleshooting these things is by using a telnet
client to separately test the server app and then the client app.  Just
telnet to the server, and type the data that the server program is
expecting.  See if you get the correct data back, or if you get cut off,
etc.   That'll tell you if the problem is on the server.

If not, test the client.  You'll need to use a proxy to connect a telnet
client to your client program, as described here:
   http://www.scottklement.com/rpg/socktut/x1085.html

>
> When I request the exact same file (as one of the locations that is
> failing), the application works fine no matter how many records.
>

Is this referring to after the delay is inserted?   If so, you may
have something wrong with the SO_LINGER settings you're using.
Otherwise, what are you talking about?  When does it fail from those
locations?  When does it succeed?

Or, is this talking about one of the locations that DOES work?

_______________________________________________
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 ...

Follow-Ups:
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.