> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Steffen DETTMER > Sent: Tuesday, August 28, 2007 2:11 AM > To: openssl-users@openssl.org > Subject: Re: SSL_peek vs. SSL_pending... > >
> I think it is important to note that a blocking read usually > should return if one single byte is available (even if more had > been requested) Correct. > and a blocking write should return as soon as at > least one byte has been written. No. A blocking write should block until all the requested data cen be written. > Of course, at least for > performance, read and write should attempt to read or write as > much as possible :-) Yes. > Also worth to be mentioned may be that the discussion is about > guarantee to return (i.e. non-blocking call), not to return the > requested data (or even any data). Especially, it is not > guaranteed that the call will work, it may fail returning an > error (right?). Any call can fail and return an error if there is an error. > For buffered communications, I assume, this should always be > possible. If there is data stored in some internal buffer (making > select returning `ready for reading'), this data must be readable > or an error must be returned. I would consider the loss of the > data from such an internal buffer an error which should be > reported (instead of blocking). `ready for writing' in such a > subsystem would mean that some write buffer has at least one byte > free and thus the next write call can return (without blocking). You are thinking 'TCP' while we are talking about the semantics for 'select'. Think about UDP. Is there anything in the standard that prohibits an implementation under memory pressure from just discarding a UDP receive queue? Now, think TCP for a second. Suppose a system received some TCP data but delayed the ACK. It unblocks 'select', but later comes under extreme memory pressure, so it discards the unacknowledged data. Now, as far as I know, no implementation does this. But nothing in the standard says it cannot do this if it wants to. > If it cannot be written for any reason I think a nice > implementation should return an error in this case. Unfortunately, that's just not possible. The problem is that this would require figuring out which socket operations are the subsequent operations that you think should not block. This can't be done reliably, and will occasionally break code that works fine now. Some code might call 'select' relying on the fact that it can't change anything. It might do this just to see if data can be written to make sure it isn't suffering a DoS attack that fills the send queue. It might then rely on a subsequent large send blocking until all data can be written (or errors). > I understand select as a call to (more or less) report the state > of some internal communication buffers and expect to make > guarantees about those buffers (no concurrent threads etc of > course). The implementation simply cannot predict the future. > In the file size example, I expect read to return 0. I made a > small test program and on linux (accidently?) it does not block > when reading a truncated file (actually, select even returns > `ready for read' on an empty file). A file is always ready. There is never anything to wait for. > David, do you mean `it cannot be guaranteed because no > implementation can be guaranteed to be 100% correct and may fail > in a complex situation' or do you mean `it cannot be guaranteed > logically/theoretically, even if the implementation is assumed to > be 100% correct, because of a logical dilemma'? One could theoretically make an implementation that did 100% guarantee it. But it would only make code that's broken appear to work and it would break some code that currently works. Consider any current program that calls 'select' just as a status-reporting function and then expects a subsequent send to block until all the data can be sent. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
