> Actually before closing a TLS connection I need to make sure that no > pending data is present on the that socket. So, calling SSL_peek would > tell if this is the case or not.
No, it won't. Okay, you call SSL_peek, and there's no pending data. Now, you're about to call SSL_shutdown. How do you know there's no pending data *NOW*? Just because there wasn't before, it doesn't mean there isn't now. The only way to know that there's no pending data when you call SSL_shutdown is for the protocol you are implementing to ensure that. Otherwise, you will always have a race. > As you are saying that SSL_peek should be called before > SSL_shutdown, No, there's no point. If you didn't know there was no data before SSL_peek, you still won't know there's no data *now* after. > then how is it ensured that the connection gets closed only if all the data > arrived on that socket is processed ? Does SSL_shutdown takes > care of this > ? or what is the significance of calling SSL_peek after SSL_shutdown ? No, the higher-level protocol takes care of this. When a request is completed, the other end will have nothing more to send. When you finish replying, what else would the other end send? If there's a "keep the connection in case and close it after a timeout", the protocol handles a close with pending data smoothly (since there's always a race in a timeout). > I am using SIP over TLS and it does not specify any such thing > related to > tls. If nobody else knows offhand, I'll do some research into SIP and see how it handles that case. No sane protocol requires you to race to shutdown and hope and pray the other end doesn't send some data at the wrong time. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
