SPDY items - client sessions and protocol names

["Alan M. Carroll" <am...@network-geographics.com>]

I've been thinking about some of the SPDY issues that have come up and have a couple of ideas.

First, the SPDY SM is really a client session. It handles input from a client socket and drives the transactions through the system, without interacting (directly) with any of the origin servers or the cache. If we take that viewpoint then we can add the concept of parent/child relationships between client sessions which in turn lets us associate a specific SPDY session with an HTTP transaction in a reasonably generic way. We would require the parent client session to keep track of which subsidiary client sessions are active but this should already be the case. We have the ClientSession cleanup clear the parent pointer and depend on the parent CS to do its own bookkeeping.

With regard to session protocols and configuration, I think I want to set up something like the HdrToken thing for protocol names, "registered protocol session names". We pre-populate it with our well known names and add any names that come in from a plugin. We can then use these indices straight up or as bit indices for tracking sets of session protocols. Beyond that we could use these for TSProtoStack rather than hard wired values.

At the intersection of these two things is the utility of being able, from a transaction (HttpSM) to be able to detect the wrapping session protocol (if any). We could either store the registered protocol session name index (because there can be only one at the session level) or we could reach up through the client session to its parent to provide that data.

Re: SPDY items - client sessions and protocol names

[James Peach <jp...@apache.org>]

On May 19, 2014, at 10:46 AM, Alan M. Carroll <am...@network-geographics.com> wrote:

> James,
> 
>> I still don't understand this focus on client session chaining. AFAICT there is no client session chaining other than an implementation detail in the current SPDY implementation. I don't see how client session is a general concept at all.
> 
> In order to do other things (such as logging) successfully, there must be some chain from an HttpSM instance to the SpdyClientSession. Where should this link be? It seems simplest and most comprehensible to me to chain it via the client session. It also makes it nicely hierarchial, that is a protocol stack.

OK, so we are not talking about a chain of client sessions, we are talking about a chain (graph?) of transaction states rooted from a client session? That makes a lot more sense to me and sounds very promising.

> Here is a picture of what I think is a reasonable data structure. Note the only change between what is there now and this diagram is the addition of parent links from the HttpClientSession.
> 

Re: SPDY items - client sessions and protocol names

["Alan M. Carroll" <am...@network-geographics.com>]

James,

> I still don't understand this focus on client session chaining. AFAICT there is no client session chaining other than an implementation detail in the current SPDY implementation. I don't see how client session is a general concept at all.

In order to do other things (such as logging) successfully, there must be some chain from an HttpSM instance to the SpdyClientSession. Where should this link be? It seems simplest and most comprehensible to me to chain it via the client session. It also makes it nicely hierarchial, that is a protocol stack.

Here is a picture of what I think is a reasonable data structure. Note the only change between what is there now and this diagram is the addition of parent links from the HttpClientSession.

Re: SPDY items - client sessions and protocol names

[James Peach <jp...@apache.org>]

On May 17, 2014, at 7:51 AM, Alan M. Carroll <am...@network-geographics.com> wrote:

>> Hmmm, is that always going to be the case? I’d imagine that we (long term) support the following types of sessions:
> 
> I think it will be. In fact, I would argue that the possible future proliferation of session mixing is another reason to have a SPDY client session, so that we can have a matching SPDY server session when/if that's useful.
> 
> If we end up wanting to bypass HttpSM, *at that point* we should create a real SpdySM that manages the connections, and we would want to have a client session object for the same reason we use it with the HttpSM now.
> 
> Having thought about this more I definitely think this is the way to go. It gives us a very nice model for our current SPDY implementation and a clear path forward when that's needful. It solves the problem of tracking the actual protocols used for a transaction - you can simply walk the client session chain and there you are. Adding plugin API to do that is trivial. It avoids having to track that data on the NetVCs, something that really breaks the abstraction and is complex. I'll try to do a better write up this weekend and pull out my ultimate design argument weapon - pictures!

I still don't understand this focus on client session chaining. AFAICT there is no client session chaining other than an implementation detail in the current SPDY implementation. I don't see how client session is a general concept at all.

J

Re: SPDY items - client sessions and protocol names

["Alan M. Carroll" <am...@network-geographics.com>]

> Hmmm, is that always going to be the case? I’d imagine that we (long term) support the following types of sessions:

I think it will be. In fact, I would argue that the possible future proliferation of session mixing is another reason to have a SPDY client session, so that we can have a matching SPDY server session when/if that's useful.

If we end up wanting to bypass HttpSM, *at that point* we should create a real SpdySM that manages the connections, and we would want to have a client session object for the same reason we use it with the HttpSM now.

Having thought about this more I definitely think this is the way to go. It gives us a very nice model for our current SPDY implementation and a clear path forward when that's needful. It solves the problem of tracking the actual protocols used for a transaction - you can simply walk the client session chain and there you are. Adding plugin API to do that is trivial. It avoids having to track that data on the NetVCs, something that really breaks the abstraction and is complex. I'll try to do a better write up this weekend and pull out my ultimate design argument weapon - pictures!

Re: SPDY items - client sessions and protocol names

[Leif Hedstrom <zw...@apache.org>]

On May 16, 2014, at 2:29 PM, Alan M. Carroll <am...@network-geographics.com> wrote:

> I've been thinking about some of the SPDY issues that have come up and have a couple of ideas.
> 
> First, the SPDY SM is really a client session. It handles input from a client socket and drives the transactions through the system, without interacting (directly) with any of the origin servers or the cache. If we take that viewpoint then we can add the concept of parent/child relationships between client sessions which in turn lets us associate a specific SPDY session with an HTTP transaction in a reasonably generic way. We would require the parent client session to keep track of which subsidiary client sessions are active but this should already be the case. We have the ClientSession cleanup clear the parent pointer and depend on the parent CS to do its own bookkeeping.


Hmmm, is that always going to be the case? I’d imagine that we (long term) support the following types of sessions:

	Client		Proxy		Origin
	———		———		-------
	HTTP		HTTP		HTTP
	HTTP		HTTP		HTTPS
	HTTPS		HTTPS		HTTP
	HTTPS		HTTPS		HTTPS

	SPDY		SPDY/HTTP	HTTP
	SPDY		SPDY/HTTP	HTTPS
	SPDY		SPDY/SPDY	SPDY
	HTTP		HTTP/SPDY	SPDY
	HTTPS		HTTP/SPDY	SPDY


In some of these cases, I’d imagine we could / should bypass the HttpSM, and have SPDY read / write to the cache directly, or talk to origins directly. In a sense, if things pan out for HTTP/2 as they like, we’d no longer have to support the HttpSM (yeah, that will never happen, but still …).

— leif