On Thu, 8 Jan 2004, Christof Drescher wrote: > I have been coding TCP/IP stacks, coding simple servers which mostly > worked as I expected, and some of this for 10 years now. I still would > call myself a beginner, but I know at least *some* things. I do not > know what a "non-blocking write" is supposed to be though, which must > be the reason I should not send data here (as Larry strongly emphasized).
Your conclusion is incorrect. I'll try to explain. For further details, I suggest that you do a search for the terms "deadlock" or "deadly embrace" in the computer science or networking literature. It can be a *very* complex topic; few people understand it implicitly. Lucky programmers go through their entire career without ever dealing with the issue. A non-blocking write means that you get an error if the output buffer is full rather than waiting until the data can be written. Most programs use blocking writes; that is, the write stalls until the entire requested data has been written. If you have a synchronous client/server, then you don't have a problem with blocking because you will never write unless the client is reading, and you will never read unless you know that the client will be writing at some point. The problem comes in when either the client or server is asynchronous. If you do blocking I/O, then it is possible to get into a deadlock in which both ends are in an I/O wait which will never be satisfied. The easiest type of deadlock to understand is the write/write deadlock. You wrote enough data to me that you are now blocked in a buffer full condition waiting for me to read the data. However, I am trying to write to you before I read anything, and my output buffer is also full. There are other forms of deadlocks, especially in protocols such as FTP which have multiple channels. Hence, the text in 5.3 should be understood to mean, "if you are even partly asynchronous, you should not allow your output buffer to fill, since otherwise you can get into a deadlock if the other end is anything other than fully asynchronous." Sending events when no command is in progress means that you are at least partially asynchronous. If you are fully asynchronous, then in effect you read and write in separate threads with no reads ever being blocked by pending writes and vice versa. Not much software is fully asynchronous. > Also, reading that paragraph, I did NOT immediately understand that it > is not ok to send status updates; just the contrary, I thought it was > a real benefit to IMAP that clients should get status updates immediately. It *is* OK to send status updates with no command is in progress, and it *is* a benefit in IMAP that clients can get status updates immediately. However, a server that sends status updates with no command is in progress must be careful not to fill up its output buffer (the TCP window). The implication is that there are synchronous clients (many/most clients are synchronous) which only read when a command is in progress. Otherwise there would be no need for the caution. > I simply accept that sending the status updates should be done only > as a response to a command, e.g. noop, and the server should not send > "blindly" to the client when no command is in progress. That isn't correct. A better statement is: Sending the status updates always works as a response to a command, e.g. noop. If the server should sends "blindly" to the client when no command is in progress, it needs to mind its TCP window to make sure it does not deadlock. > I have no problem with it - the clients we're using here (MS) are doing > very well with their IDLE support; I just wondered that those other > clients, as good as they may be, do not support IDLE and therefore > need some time to get updates via NOOP or the like. Shouldn't be > support for IDLE a strongly suggested feature for clients? Most synchronous clients do something to poll the connection within a minute or two. I don't know about anyone else, but I'm not so hyperactive that I can't wait a minute or two to see my newly-arrived spam... :-) -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
