Hi Oleg,
first of all, I think you are "misusing" TCP as a queue here (and at least our implementation is not really meant for this). It might work (or not, as you see), but in my opinion, the various timeouts implemented by various stacks impose the risk that your setup won't work if you change the client's system (e.g. update windows).
If I read correctly, by now you reported 2 possible issues:
1) segment is accepted but old window size is sent
I'm not sure what's best here. Of course, we must prevent silly window updates during normal operation. In your case, it would probably have been OK to send the actual/real window size, but we would haveto find a way to decide when it's OK and when not...
2) after storing a segment in "refused_data", no more ACKs are sent
The whole purpose of "refused_data" was to let the stack behave like a buffer overflowed: if your device cannot handle incoming data in the speed it is sent by the remote host, the remote host should throttle its sender. This is achieved by not handling/not answering a packet at all, just like it was dropped due to congestion. This should bring the remote host's TCP to send less. ACKing an old seqno instead might work for you, but I don't know what will be the result for all remote stacks, so I'm very reluctant to change this...
As you can see from this, TCP is meant to achieve the highest possible throughput possible for the combination of remote host, network and local host. What you want instead to make it a queue that keeps up a connection as long as possible without data being exchanged. I'm not fully convinced one can coexist with the other, but please come up with suggestions of how to fix this ;-)
Simon