Mark Williams wrote: > There is one added complication in that the protocol is a datagram > protocol at a > higher level (although it uses TCP). I am concerned that the whole > protocol could > block if there is not enough data to encrypt a whole outgoing message > but the peer cannot > continue until it gets the message.
What do you mean by "not enough data to encrypt a whole outgoing message"? The only way it can block is if each side is waiting for the other, and if that happens, the application protocol is broken anyway. There is no way this logic can cause one side to internally block. The 'cork' logic only stops us from reading if we have already read data the application has not processed yet. If the application does not process read data, then it is broken, but we are not. The write queue logic only stops us from accepting data from the application to send if we have unsent data. If the other side does not read this data, then it is broken but we are not. In fact, any application layered on top of TCP is broken if it cannot handle a TCP implementation that permits only a single byte to be in flight at a time. If it *ever* allows each side to insist on writing before reading at the same time, it is broken. On the off chance you do have to deal with a broken TCP-using application (and you do all too often), just make sure your queues, in both directions on both sides, are larger than the largest protocol data unit. (More precisely, the amount of data both sides might try to write before reading any data.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
