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



The SO_LINGER is currently set to 120
This may be the key because the user does say that the PC program sits for a
couple of minutes before it ends without retrieving all the records.
Would it be abnormal for a PC program to take 2 minutes to read 10,000 bytes

of data? It takes the iSeries .05 (5 hundredths of a second) to send the
data. 

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.

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.

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.

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.

Thanks for your help



-----Original Message-----
From: midrange-l-bounces+jallen=drvtech.com@xxxxxxxxxxxx
[mailto:midrange-l-bounces+jallen=drvtech.com@xxxxxxxxxxxx] On Behalf Of
Scott Klement
Sent: Monday, September 08, 2003 3:40 PM
To: Midrange Systems Technical Discussion
Subject: RE: Socket program problem



On Mon, 8 Sep 2003, John Allen wrote:
>
> Linger is set to 2 minutes. What is this linger value used for? When would
I
> want to increase or decrease the value?

When you issue a close() on a socket, normally the close() will wait
("linger") until all of the data you've previously written to the socket
has been sent to the remote side of the connection.

The SO_LINGER value you set with setsockopt() determines how long the
close() API will wait before giving up.   So, in your case, it may make
sense to try increasing it.


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

Doesn't sound like that's your problem, then.

> 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 & > <)

Sockets are 8-bit transparent.  In other words, any value can be sent over
a socket without causing an error like WSAECONNABORTED


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

It waits as long as the SO_LINGER value for the PC to receive it all, then
drops what's left.  That's why I keep coming back to that SO_LINGER value
:)

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

In Winsock, you can have Windows send you an "event" message every time
data is received.   Is that what he's talking about?   If so, it's 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.

Then I guess I don't know what you mean by acknowledgement?  Is your
iSeries program sending some kind of ack that he's using?

If, as I suggested before, you're talking about the Windows event message,
he should get one every time data arrives, no matter how big the data is.
So, if you send 10000 bytes, and he's receiving 500 each time, he should
get 20 event messages.

Of course, for each message he gets he needs to use care that he reads
everything in the socket buffer.  Otherwise, there will be data that
Windows has told him about, but that he hasn't read.   That's a
possibility, here...

> It seems to me the PC should continually do receives until it gets a
message
> back that the socket is closed?

That's possible if this is a multithreaded app.  If not, a Windows app
needs to monitor for event messages periodically, it cannot sit in a solid
loop of recv's...   if it just sits on recv() it'll look to the user as if
the program's not responding.

But, this is starting to get a bit off-topic for this forum.  Let's talk
about the iSeries side :)

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