On Sep 22, 2014, at 5:51 AM, Susan Hinrichs <shinr...@network-geographics.com> wrote:
> > 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. Ok, that makes sense. thanks! J
