🚀 go-pugleaf

"SF" <invalid@NOSPAMinvalid.com> wrote in message
news:44c866d6@newsgroups.borland.com...

> The help (BCB5) states to set the Count parameter of
> TWinSocketStream::Read "fairly low, and make several calls
> to Read, rather than fewer calls with a large value of Count".

Ignore that.  It doesn't matter what you set the Count to, as long as you do
not set it to 0.  Make sure that you are calling WaitForData() before
calling Read().  Then Read() will return however much data is actually
available, up to a maximum of your specified Count.  And then use the return
value to know how much was actually read.

> Could a too low value of Count result in an overflow of
> the TCP/IP stack

No.


Gambit

> Ignore that.  It doesn't matter what you set the Count to, as 
> long as you do
> not set it to 0.
Then once more I wonder why they write a so clear (but wrong) 
explanation in the help... maybe could it depend on the 
operating system?

> Make sure that you are calling WaitForData() before
> calling Read().
Of course, I do.

> Then Read() will return however much data is actually
> available, up to a maximum of your specified Count.  And then 
> use the return
> value to know how much was actually read.
Exactly what I'm doing, but thanks for confirming that's the 
right way.

>> Could a too low value of Count result in an overflow of
>> the TCP/IP stack
>
> No.
OK. Anyway, does the TCP window depend on how fast I read the 
data from the socket or is it a completely different layer?

Thank you very much.

Stefano. 

"SF" <invalid@NOSPAMinvalid.com> wrote in message
news:44c9b42a@newsgroups.borland.com...

> OK. Anyway, does the TCP window depend on how fast I
> read the data from the socket or is it a completely different layer?

TCP windows are handled at a much lower level.  99.9999% of the time, the
application does not need to worry about them.


Gambit

> TCP windows are handled at a much lower level.  99.9999% of 
> the time, the
> application does not need to worry about them.
Good. Although I'd be curious to know that 0.0001% now...

Besides that, what happens if a connected socket (client or 
server, blocking or non-blocking doesn't matter) receives a lot 
of data, but the application doesn't read it (or it's not fast 
enough)?

Is it like a serial port that after a while there's a buffer 
overflow (with loss of data)?

Thank you so much. I appreciate your replies.

Stefano. 

"SF" <invalid@NOSPAMinvalid.com> wrote in message
news:44ce1ea3@newsgroups.borland.com...

> what happens if a connected socket (client or server, blocking or
> non-blocking doesn't matter) receives a lot of data, but the
> application doesn't read it (or it's not fast enough)?

The unread data remains in the receiving socket's internal buffer.
Eventually, the buffer will fill up.  Once the buffer cannot accept any
further data, the sending side will do one of the following:

1) if the sending socket is non-blocking, then any writing will fail with an
WSAEWOULDBLOCK error until the receiving buffer has been cleared.  At which
time the sender will receive a FD_WRITE notification indicating that the
socket can be written to again.  In the meantime, any outbound data that
returned a WSAEWOULDBLOCK error would have to be cached so that it can be
sent at a later time so that it is not lost.

2) if the sending socket is blocking, then any writing will simply block
until the receiving buffer is cleared.  Unless there is a writing timeout
applied to the socket, in which case the writing will fail if the timeout
elapses.

> Is it like a serial port that after a while there's a buffer
> overflow (with loss of data)?

No.


Gambit