Hi Darrel, Thanks for the very useful and clear explanation.
> Mark 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 is not allowed is for the stack to > hold onto the > data (possibly forever) in the hope that the user will make > an API call to write more data. In this case my concerns are unfounded. > Now there is another issue which isn't really a blocking one, > it is more > a "deadlock". This is where due to your IO pump design and the > interaction between the upper levels of your application and the > datagram/SSL levels you ended up designing your application such that > the same thread is used to both service the IO pump and the > upper levels > of the application (the data processing). This is possible > but requires > careful design. For whatever reason the upper levels stalled/blocked > waiting for IO, and this means your thread of execution lost > control and > starved the IO pump part from doing its work (because its the > same thread). The IO pump thread would definitely be independent of all other layers of the protocol. I don't like mixing layers. Regards, Mark. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
