On Oct 17, 2013, at 3:23 PM, Uri Shachar <[email protected]> wrote:
> On Thu, 17 Oct 2013 11:45:41 -0700 James Peach wrote: >> On Oct 13, 2013, at 2:15 PM, Uri Shachar <[email protected]> wrote: >>> On Wed, 9 Oct 2013 10:41:42 -0700 James Peach wrote: >>>> On Oct 8, 2013, at 1:19 PM, [email protected] wrote: >>>> >>>>> Updated Branches: >>>>> refs/heads/master 7ba121c9a -> 3c0c835c1 >>>>> >>>>> >>>>> TS-2268 Add support for opening protocol traffic sockets through the >>>>> traffic_manager. >>>> >>>> - How do plugins use this to accept on SSL sockets? >>> >>> In the current implementation - they don't. There are a couple of issues to >>> consider here: >>> 1) How do we allow protocol ordering (what if I want a protocol plugin to >>> handle the connection _before_ the SSL engine) >> >> What's the use case for this? A plugin that implements it's own TLS? Is that >> needed? > > I can think of a number of use-cases in my (admittedly less common) > transparent deployment land - but how about this: > ATS is the frontend to all your servers and you want ATS to handle some > encrypted connections but not others - making the determination based on SNI > -> > > Protocol plugin that parses SNI information from the request, passing > connections to the SSL engine if they can be handled locally and acting as a > tunnel to the OS if they can't. OK, so in this case, the plugin is listening on a server name? Or does it need to dynamically choose to sometimes accept on a server name? Does this API help us get closer to that feature? >>> 2) Protocol Plugin chaining implementation >> >> Again, what is the use case? I'm not sure that protocol plugin chaining >> would look like ... > > Encapsulated protocols for example - where you want to have a clean state > machine handling each protocol and handing it off to the next one (Sort of > like what you did with SPDY). > I'm not sure what a full implementation of this would look like either.... It sounds interesting in princple :) but maybe off topic for this API discussion? >>>> - We already have 3 *Accept() APIs, why can't they support this >>>> requirement? >>> >>> Isn't it worthwhile to have a way to specify that we require the port to be >>> pre-opened? The other option I can see (without adding API like >>> TSPortDescriptorRendevous) would be to pass a flag.... >> >> I'm not sure that it's worthwhile. If it's protecting against traffic_server >> crashes, that seems nice to have, but maybe not very important. Is that the >> only use case? > > Yes - and it's a very important one for some transparent deployments. If the > proxy hangs connections for a second or two, most likely users won't notice > -- if they all get a reset then you're bound to get support calls. Ah, thanks. Thats something that I did not consider. There's some interesting features that you are talking about here. I'd like to bring the discussion back to the specific API. Does this API help us get there? What can we do to address the concerns that I raised about it? J
