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




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


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.