Ken Giusti commented on PROTON-136:
Re: the api naming - yes, I totally agree that "link" and "session" are bad
choices for this new api. And now that you mention it - yes, we certainly can
preserve the 'old' api and just extend the api model a bit to support a top
level "container" for SSL connections (and thus, SSL sessions).
Not 100% sure I like the "config" name - there may be other non-config-y things
we could do with the top level object, like query it for state or statistics,
which really isn't "config" like. And I don't want to use 'context', which is
perfect but conflicts with the existing conventions for user-supplied context.
How about "domain"?
In any case, let's leave the existing API in place, and extend it as follows:
// new top level object - container for related SSL connections:
pn_ssl_domain_t *pn_ssl_domain( pn_ssl_mode_t );
pn_ssl_domain_free( pn_ssl_domain_t * );
// create a new SSL connection "owned" by the domain:
pn_ssl_t *pn_ssl_new( pn_ssl_domain_t *, pn_transport_t *)
pn_ssl_free( pn_ssl_t * ) // no change here
// new domain-based configuration api:
// new object to represent the state of a single SSL connection
pn_ssl_state_t *pn_ssl_get_state( pn_ssl_t *);
int pn_ssl_resume_state( pn_ssl_t *, pn_ssl_state_t * );
void pn_ssl_state_free( pn_ssl_state_t * );
bool pn_ssl_state_resumed_ok( pn_ssl_t * )
> 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
> 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
> >>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. ;-)
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