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);
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

Reply via email to