"Christof Drescher" <[EMAIL PROTECTED]> wrote: > 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?
Right. > 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? Not quite. The server is allowed to *try* to send unsolicited data unilaterally, but if that data cannot be sent right away due to a full buffer, then the server is not allowed to wait for the buffer to clear and for that data to be sent before it checks for a command from the client. If the attempt to send unilateral data succeeds in non-blocking mode, great - either the client is asynchronous too, and will really benefit, or we just haven't filled up our buffer yet. If the attempt fails due to a full buffer, then the client is probably not asynchronous, and it won't try to read any responses until after it sends a command. The server must go back to waiting for a command. Once it receives one, it can send as much untagged data as it likes, even in blocking mode, because in this state, it is the client's responsibility to read the responses before writing any more commands. The client will read the previously-sent unilateral data, clearing the buffer and making room for the response to the current command, which will be read next. >> 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. > > 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. I think what Larry means is that since EXPUNGE can be sent in response to some commands, but not others, it cannot be sent unilaterally, when no command is in progress, because the next command might be FETCH, etc. paul
