Subject: [hybi] Divisibility of the sever ?

From: Greg Wilkins <[email-masked]>
Date: Mon, 27 Sep 2010 16:54:59 +1000

The draft-02 contains the following new text in section 5.2:

                        Servers may offload the management of the
connection to other agents
			on the network, for example load balancers and reverse proxies. In	
			such a situation, the server for the purposes of conformance is	
			considered to include all parts of the server-side infrastructure	
			from the first device to terminate the TCP connection all the way to	
			the server that processes requests and sends responses.	
				
			EXAMPLE: For example, a data center might have a server that responds	
			to Web Socket requests with an appropriate handshake, and then passes	
			the connection to another server to actually process the data frames.	
			For the purposes of this specification, the "server" is the	
			combination of both computers.

I completely agree that the combination of all server side components
must act as if they were a single compliant agent.

I do understand that organizations like google will (for good reasons)
probably have their own proprietary protocols that work between load
balancers, proxies and applications servers, and I'm certainly not
advocating that we change the text to imply that such aggregate agent
solutions are not compliant.   However, I believe that we also need
make some efforts to encourage interoperability between components.
For many (if not most) deployments, the various server side components
will be provided by different vendors and different organizations and
it is vitally important that we encourage interoperability between
such components.

So could we also add the following text.

    Components that offer offloaded websocket services which may be provided
    or administered separately from other server side websocket components
    SHOULD for the purposes of interoperability act both as as compliant
    servers to upstream agents and as compliant clients to downstream agents.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Sep 2010 09:41:27 -0400

>     servers to upstream agents and as compliant clients to downstream agents.

Greg, I really like when people express their opinions as ietf-draft
diffs. Thank you.

But I don't support this particular fragment :)

As I read it it seems to officially discourage websocket to * gateways..
and frankly while I appreciate the sentiment, that's an implementation
and product concern, not one of the websocket protocol per se. IMO, The
purpose of the protocol spec is not to be a best practices document.
Keep it as tight as possible - we're having enough problems producing
that much in a reasonable amount of time!

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Sep 2010 08:01:35 +1000

On 27 September 2010 23:41, Patrick McManus <[email-masked]> wrote:
> and product concern, not one of the websocket protocol per se. IMO,

I kind of see that.  But my concern remains that the spec is currently
very light on when it comes to expected behaviour of intermediaries
and the text added in -02 appears to officially discourage
decomposition of a server into standard based interoperable
intermediaries.

But then I also agree that we should not discourage websocket to
gateways that might convert to some other protocol. So how about this:

    If a server offloads websocket services into a component that is acting as a
    websocket intermediary, then the component  SHOULD for the purposes of
    interoperability act both as as compliant servers to upstream agents and as
    compliant clients to downstream agents.

I think we probably also need a whole section on intermediaries - but
at least for now a paragraph like that is a gentle push in the right
direction.

cheers

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Sep 2010 19:23:14 -0400

On Tue, 2010-09-28 at 08:01 +1000, Greg Wilkins wrote:
> :

+1 on having a section on intermediaries. And saying that an
intermediary MUST be a compliant client and server is a fine thing in my
opinion. When would it be ok for it not to be afterall? 

(which is kind of a trick question, if it isn't compliant websockets
then it is a gateway into something else instead of a websockets
intermediary.)

---

From: John Tamplin <[email-masked]>
Date: Mon, 27 Sep 2010 19:27:36 -0400

> then it is a gateway into something else instead of a websockets

You could have a "composite" intermediary which uses a non-WS protocol in
the middle, but is WS on the ends.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 28 Sep 2010 10:46:51 +1000

> the middle, but is WS on the ends.

I think the same form of words that has been use to explicitly permit
composite clients and servers needs to be applied to explicitly permit
composite intermediaries.

So this mostly comes back to not having a section on intermediaries.

However, I'm still uncomfortable with the wording in the current
draft, as it cites load balancers and reverse proxies as examples of
composite servers.  While some may see them as composite servers, I
think just as many will view them as intermediaries.   So maybe for
now we can just delete the text: "for example load balancers and
reverse proxies" from the paragraph below:

   Servers may offload the management of the connection to other agents

to avoid pigeon holing these types of components as parts of a composite server.

cheers

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Sep 2010 07:18:58 +0200

Hi Greg,

> to avoid pigeon holing these types of components as parts of a composite server.

I think you're right here. In fact we're speaking about two types of
intermediaries :
  - the standard ones which have to support both HTTP and WS (LBs,
    rev-proxies, ...)
  - WS-offloading components which will handle a part of the WS
    framing and will transfer whatever remains to another server

The first ones must indeed be standard and not indicated to be part of
the server itself, precisely because they can't judge about the protocol
until the server has replied with the 101+upgrade. The second ones are
the WS server itself, and can talk whatever protocol they like with their
backends.

Cheers,
Willy