trafficserver-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: git commit: TS-2268 Add support for opening protocol traffic sockets through the traffic_manager.
Date Thu, 17 Oct 2013 22:49:19 GMT
On Oct 17, 2013, at 3:23 PM, Uri Shachar <ushachar@hotmail.com> wrote:

> On Thu, 17 Oct 2013 11:45:41 -0700 James Peach wrote:
>> On Oct 13, 2013, at 2:15 PM, Uri Shachar <ushachar@hotmail.com> wrote:
>>> On Wed, 9 Oct 2013 10:41:42 -0700 James Peach wrote:
>>>> On Oct 8, 2013, at 1:19 PM, ushachar@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.

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

Mime
View raw message