[ https://issues.apache.org/jira/browse/PROTON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13531121#comment-13531121 ]
Ken Giusti commented on PROTON-136: ----------------------------------- Rafi has mentioned a minor change to the proposed API: 1) don't deprecate pn_ssl_t *pn_ssl( pn_transport_t *), and 2) modify the constructor: pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *domain, pn_transport_t *transport, const char *session_id); to: int pn_ssl_init( pn_ssl_t *ssl, pn_ssl_domain_t *domain, const char *session_id); So, to create an SSL connection, two steps are done: ssl = pn_ssl( transport ); // access transport's ssl, or construct if none. rc = pn_ssl_init( ssl, domain, "id" ) // initialize, The modified API would prevent the ambiguity possible with the first approach - say calling the pn_ssl_new method for a transport that already has an SSL with a different domain than was used when the ssl object was originally constructed. Rafi - is this correct? > Add support for SSL session resumption > -------------------------------------- > > Key: PROTON-136 > URL: https://issues.apache.org/jira/browse/PROTON-136 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c > Affects Versions: 0.3 > Reporter: Affan Dar > Assignee: Ken Giusti > Labels: ssl, sslContext, sslresume > Attachments: PROTON-136-initial-Java-and-Python.tgz, > ssl-patches-20121212.tar.gz > > > Open SSL supports resumption of SSL sessions which by-pass the heavy SSL > handshake process. This is critical for scenarios involving low powered > devices especially on cellular data networks where bandwidth is precious. > It would be great if Proton exposes this ssl resume feature to users. . > From: rhs [mailto:rschlom...@gmail.com] > Sent: Tuesday, November 13, 2012 11:34 AM > To: Affan Dar > Cc: David Ingham > Subject: Re: SSL session resumption > On Tue, Nov 13, 2012 at 8:05 PM, Affan Dar <affan...@microsoft.com> wrote: > >>Serializing/restoring the whole session state for the messenger will work > >>for the scenario I think. > Ok, let's start with this step then. I'm open to providing something finer > grained if there is a need, but my preference is to keep it simple for the > moment. > > >>One more thing, RFC 5077 has another flavor of session resumption which > >>openssl supports (original >>implemented as RFC 4057 back in 2007 I think). > >>This allows us to resume sessions without carrying state >>on the server > >>side which as you can imagine is a big deal for service vendors. Probably > >>there is no API >>level impact if messenger handles the session state > >>itself but just wanted to put this on your radar. > Ok, good to know. > Could one of you file a JIRA for this upstream? I'm trying to get things a > little more organized on the process front and keep everything centralized in > JIRA. ;-) > --Rafael -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira