On Thu, 17 Oct 2013 11:45:41 -0700 James Peach wrote: > On Oct 13, 2013, at 2:15 PM, Uri Shachar <ushac...@hotmail.com> wrote: >> On Wed, 9 Oct 2013 10:41:42 -0700 James Peach wrote: >>> On Oct 8, 2013, at 1:19 PM, ushac...@apache.org 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. > >> 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.... > >> >> >>> - 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. > >> I don't see a problem with creating multiple variants (in the API layer >> only) to emphasise the difference in behaviour. > > No, I think it's fine if it's necessary. But it's preferable to have a > smaller API surface so that developers can reuse their knowledge and have > fewer APIs to learn. We also have an easier time documenting and teaching a > smaller API set. > >> >>> - The name breaks API conventions (ie. there's no such object as a >>> TSPluginDescriptor) >> >> Agreed - TSNamedAccept(STRING) maybe.... >> >>> I think that a more generally useful facility would be to consider >>> extending the TSPortDescriptor to handle requirement (2). The trick for >>> this will be that traffic_manager has to open the sockets and listen(), but >>> not ever accept(). This means that we need to communicate the descriptor >>> string to traffic_manager. Here are some suggestions on how we could do >>> that: >>> >>> a) Add a owner=STRING tag to the socket descriptor. This could cause >>> traffic_manager to listen but not accept. A subsequent call to a new API >>> TSPortDescriptorRendevous(STRING) would return a corresponding >>> TSPortDescriptor that can be used with TSPortDescriptorAccept(). >> >> In progress on the first half - I dislike TSPortDescriptorRendevous for two >> reasons: >> 1) 99.9% of uses would call TSPortDescriptorRendevous and then >> TSPortDescriptorAccept > > Yep, but that's trivial to do. > >> 2) Multiple ports with the same owner tag will make the API a bit more >> complicated since we'll need to return a list > > Good point. That's a good argument for not bouncing through a > TSPortDescriptor object. > > J
