What does that mean? Are you explicitly creating a buffer of a limited size? If so then it is something your program is doing that we do not know how it works. If your program is not explicitly creating a buffer of a limited size then what buffer are you asking about?
“When a client (or server – but it is usually the client) advertises a zero value for its window size, this indicates that the TCP receive buffer is full and it cannot receive any more data. It may have a stuck processor or be busy with some other task, which can cause the TCP receive buffer to fill. Zero Windows can also be caused by a problem within the application, where the TCP buffer is not being retrieved.
A TCP Zero Window from a client will halt the data transmission from the server side, allowing time for the problem station to clear its buffer. When the client begins to digest the data, it will let the server know to resume the data flow by sending a TCP Window Update packet. This will advertise an increased window size and the flow will resume.”
Size of my buffer is equal to TCP buffer, through the stream.GetBufferSize property, so explicitly created.
So, if I’m stuck somewhere else, and I’m not reading my stream, will I lose some information, or something else will happen? That was the question.
I think the documentation you quoted is saying that TCP will not allow the other end to send more data until you process some data from the buffer.
If you are only receiving data and there is not need to send feedback after processing some of the data then you could write data out to a disk (SSD) file and then read from that file to process. You could do it all in memory but if the system crashes then you would lose data. I am sorry but I do not know if the data in the TCP buffer would be lost if the system crashes. I would think that it would be best to ensure the buffer does not fill up and that the data should be processed quickly, even if it must be written to a disk file first.