EDIT: I think i get it now. So a simple sliding window mechanism basically assumes the correctly received data is processed immediately. Therefore an acknowledgement implies the data was received AND processed, so the sending host can send as many new bytes as bytes beeing acknowledged.
In a real world scenario the data isn't processed immediately but rather buffered by the receiving TCP, so we need a variable sized receive window since it's indeed possible for bytes to be acknowledged but not yet processed (and therefore still in the recieving buffer).
The receiving window property in the tcp header basically tells us how much space there is left in the buffer at the time the ACK was sent, so the sender can send up to that many bytes (minus the unacknowledged bytes still in transit) to always make sure not to overflow the receiving host.
I would still really appreciate an answer if i understood this correctly.
Original Question:
i'm currently reading a book about networking and have a question regarding flow control.
As far as i understood each host has a send-buffer where byte-sequences remain that are in transit (or already received by the other host) but not yet acknowledged. And if there is still room within the buffer that is not occupied by not-yet-acknowledged-byte-sequences he can send that many bytes basically without receiving anything from the other host.
On the other hand each hosts has a receive buffer where byte-sequences remain that were correctly received but not yet read() by the upper layer.
The amount of bytes the sender is able to send without having to wait for a acknowledgement depends on how many more bytes the receiving buffer can store. This is basically what's inside the receive-window header field.
Now my question:
In the book i read (and in other ressources), the process (sliding window) was explained such that whenever the sending host receives an ACK for some bytes he can basically "move the window" and has new free space to send more data.
What i don't understand is the correlation between the ACKs and the recieve window property. I read everywhere that the sending host has to wait for another ACK if the receive window is zero (the receive buffer is full basically). But doesn't an ACK only tell me the data was received successfully opposed to "data has been read() from the receiving buffer so there is new space, you can send more bytes"?
I can't see the correlation between ACKs and the receive window property. It would make sense if the ACK is send whenever the bytes are read() from the recv buffer opposed to being received successfully, but i doubt that's the case.
Is it possible that all the packets a host sent are acknowledged but the receiving buffer is still full? This would also be kind of weird since i assumed as soon as a packet is acknowledged it's deleted from the sending buffer.
In this case there would be no correlation between the remaining free space in the send-buffer and the data the host can still send. Since the send buffer could be empty if all packets are ack'ed but the recv-buffer could be full (because the packets are received but not read() yet.
This is probably kind of a mess since i can't pinpoint my question, especially since my english skills aren't superb, but i really hope someone might be able to dissolve my confusion.