Caching large projects hang forever about ucs HOT 2 CLOSED

Re-reading the packet capture, the first TCP ZeroWindow flag is sent by the server to the client.

This indicates to me that the server first fills up it's TCP and/or read-buffers, then parses a command, sends a reply and then waits for the client to read the data. I suspect that the client sends off all it's get-requests and then wait for replies to come in. A deadlock in other words ... and then a TCP timeout.

from ucs.

It turns out that the editor expects to send off all it's requests before reading any responses, while the server expected the protocol to be straight up request-response protocol (a la HTTP).

For small projects, the discrepancy would be hidden by filling send/receive TCP buffers and what the buffered sender could absorb.

For large projects buffers would fill up all over and eventually cause a deadlock, expressed as a TCP timeout when nothing happened.

This has been fixed by #23 where a queue of 100k get-requests has been set up, so cache-requests will be processed and sent as they are consumed by the editor.

from ucs.