On 9/21/2014 6:37 PM, James Peach wrote:
On Sep 17, 2014, at 10:17 AM, Susan Hinrichs <shinr...@network-geographics.com>
wrote:
I've updated my branch (https://github.com/shinrich/trafficserver/tree/ts-3006)
and documentation (http://network-geographics.com/ats/docs/ssl-api.en.html)
based on feed back from James a couple weeks back.
I took all of James' recommendations with two exceptions.
Instead of
tsapi TSReturnCode TSVConnTunnelToAddr(TSVConn, const struct sockaddr *);
I implemented
tsapi TSReturnCode TSVConnTunnel(TSVConn);
It looks like the current API uses a separate call to change the origin server
address, e.g.
tsapi TSReturnCode TSHttpTxnServerAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr);
Of course that exact call would not work in the SSL case because we don't have
a TSHttpTxn object, but perhaps we could eventually add a similar function like
TSVConnServerAddrSet(TSVConn, struct sockaddr *)?
So, I guess I don't understand why TSVConnTunnelToAddr is not useful? Could you
elaborate?
It seemed like the existing APIs followed a more feature orthogonal
approach of having one API to set the ServerAddr and another to indicate
tunneling. There exists a TSHttpTxnServerAddrSet. It would seem to be
more consistent to add a TSVConnServerSet and a TSVconnectTunnel instead
of a combined TSVconnTunnelToAddr.
Instead of
tsapi void TSVConnReenable(TSVConn, TSEvent);
I implemented
tsapi void TSVConnReenable(TSVConn);
It was not clear to me, where the event parameter should be sent.
In the absence of an event parameter, what's the right way to abort the VC with
an error?
From your original comments, you suggest the following
To abort the connection you could use TSVConnClose(),
TSVConnAbort() or TSVConnShutdown() (not quite sure which one you
should pick!).
That said, we could add an event for future use. Perhaps there will be
some scenario to send an event to something in this case in the future.
