Hi, thank you for your message. Makes things clearer (technically).
> The problem is that a server can't send data to a client until it can > GUARANTEE that the client has a recv() outstanding on the socket. > Otherwise it's possible that the servers send() command will block (this > happens when the TCP buffers on the client fill up, which causes the > client to flow control the connection, then the TCP buffers on the > server fill up, then sockets will cause the send() command to hang until > all the downstream buffers are freed up). Just wondering: A server can never GUARANTEE that a client as a recv() outstanding on the socket while no command is in progress, can it? Since no client can tell the server that it DOES a recv() by any means, it must assume that there is NO outstanding recv(), right? If so, the whole paragraph 5.3 about it would simply be superfluous, wouldn't it? I really don't mind, I have my answer (sending updates just as a response to client commands in progress seems the way). > In addition, you about the only unsolicited status updates you can send > to the client are EXISTS, RECENT and FLAGS updates, EXPUNGE updates are > absolutely verboten. And if you ever get to the point where you would > want to send an EXPUNGE update, you need to stop sending updates to the > client because the sequence numbers would get out of date with after > this. Wow, we just had the topic about EXPUNGE, which must not be sent at FETCH/EXISTS/SEARCH, but may be sent on any other command. This was never doubted. Do you? Christof
