Re: [hybi] HyBi Design Space

thx salvatore for typing this up. it looks good, but i have one very
minor nit and a comments/question.

the nit is that when we use the verbiage in section 6.2:

"Non-browser HTTP:  A bidirectional client may be written outside of a
browser and use bidirectional web transports.  Typically this is done
so that a rich or minimal client can bypass firewalls to access public
servers over HTTP transports.  Examples include the Comet Java client
and the Second Life Viewer."

it could be interpreted that the reason we use HTTP is exclusively to
move through firewalls easily. the main reason we layer some of our
protocol over HTTP is that we wanted / needed a protocol with request
/ response + metadata semantics. that it goes through firewalls is a
pleasant side-effect. i suspect that other users of HTTP as a
substrate might have come to the idea for the same reasons. could i
recommend the minor change of:

"Non-browser HTTP:  A bidirectional client may be written outside of a
browser and use bidirectional web transports.  Typically this is done
when a rich or minimal client requires a mature transport for
application protocol with request / response semantics and/or the
ability to bypass firewalls to access public servers over HTTP
transports.  Examples include the Comet Java client and the Second
Life Viewer."

and the comment/question:

1. towards the end of the breakfast bof we discussed... for lack of a
better term... "features" like message multiplexing so that when
independent components on the server want to send an unsolicited
message to independent components on the client may use the same
connection. in other words, allowing a single connection to carry
messages for multiple channels. that's still being discussed, right?

we sorta figured that it won't be an unusual case to find you have a
large number of components on the client that need to be addressable
by independent components on the server. my read of websockets seems
to imply it punts on the issue, requiring application developers to
design such a scheme for themselves. that sorta makes me a little
uneasy. when your client is a web browser that downloads a web page,
instantiates a number of javascript objects described by javascript
files on the server, i can see that this provides a great deal of
flexibility. but the SL viewer won't be downloading and executing
javascript for something as critical as server to client messaging,
and i would venture to guess that other applications that use HTTP as
a substrate will find this idea concerning.

if we were to implement messaging over websockets, i believe we would
be inclined to define a static client service that consumes the
protocol, but assumes a payload with a field that identifies a
uniquely addressable destination component in the client.

if we're going to define such a scheme and enshrine it in c++ on our
client, it would be very nice, since it's not going to change very
much, if it were vaguely standardized so we could get intermediaries
to understand the request and potentially cache them.

this is my round-about way of saying, we like rhttp and bwtp because
they allow intermediaries to reason about reverse-requests, caching
reverse responses when appropriate, routing around firewalls when
appropriate (like a bwtp aware socks stack) and allow us to use design
patterns we're familiar with (like web capabilities) in the reverse
direction.

since i've rambled, let me repeat my question.. "we're still going to
add message multiplexing, right?"

if yes, i'll just shut up now and wait to comment when the draft is published.

if no, i'd love to chat about it a little more.

-cheers
-meadhbh / infinity

--
   infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
         http://wiki.secondlife.com/wiki/User:Infinity_Linden

On Thu, Oct 8, 2009 at 13:50, Salvatore Loreto
<salvatore.loreto@ericsson.com> wrote:
> Hi there,
>
> at the breakfast BoF in Stockholm it was brought up that it would have been
> helpful to more
> clearly describe the design space, including the programming environments
> (client, server, library, etc.), deployed infrastructure (routers, proxies,
> etc.).
>
> here the analysis that we have written down and we are going to insert in
> the draft-loreto-http-bidirectional.
>
> comments, feedbacks and suggestions are very welcome
>
> cheers
> Sal
> www.sloreto.com
>
>
>
> 6.  Design Space
>
>  In order to define additions to HTTP that could enable improved
>  mechanisms for bidirectional HTTP or new bidirectional protocols, it
>  is important to map out the design space and potential design
>  alternatives, with special attention to deployed infrastructure and
>  programming environments.
>
>  In existing HTTP-based systems, the typical semantic is client-server
>  Representational State Transfer (REST), where the resources served
>  are closely associated with an entity known by a URI or URL.
>  However, the introduction of bidirectionality can significantly
>  change the normal HTTP patterns.
>
>  As one example, the standard roles of client and server can be
>  reversed and a server can request resources from a client.
>  Unfortunately, due to a lack of client addressability URL's may not
>  be applicable to client entities and new addressing paradigms may be
>  required.
>
>  Furthermore, bidirectionality introduces a message passing pattern
>  into the traditional REST style.
>
>  These additional semantics will influence the design of the
>  bidirecitonal protocols, addressing, and APIs.  Without a strong
>  association between an identified entity and a resource, new
>  mechanisms for content distribution and caching messages might need
>  to be considered.
>
>  In the next sections we analyse the design space from several
>  different sides of the HTTP deployed infrastructure, including
>  clients, servers, and intermediaries such as proxies, caching
>  servers, and load balancers.
>
>  The process of evaluating eventual improvements to the bidirectional
>  solutions or development of new bidirection protocols should take
>  into consideration the following concerns and criteria:
>
>  Complexity:  enables ease of implementation, understanding, and
>     debugging
>
>  Capability:  addresses all/most known bidirectional use-cases
>
>  Extensibility:  has the capacity to handle new use-cases
>
>  Latency:  defines minimal, average, and maximal latency for message
>     delivery
>
>  Bandwidth overhead:  minimizes overhead for idle and busy usage
>
>  Scalability:  has the ability to handle large scale usage
>
>  Footprint:  has the ability to handle small devices and/or massive
>     replication ("cloud")
>
>  AAA:  enables proper Authentication, Authorization and Accounting
>
>  Security:  enables strong security for integral, confidential,
>     endorsed, and cross domain deployments.
>
>  Interoperability:  can work with and/or be integrated with existing
>     bidirectional implementations
>
>  Compatibility:  can work with existing web infrastructure for
>     distributing, caching, manipulating, and displaying content.
>
> 6.1.  Server side
>
>  The server side can be decomposed into three categories:
>
>  In-band HTTP:  Bidirectionality is part of the normal HTTP/Web server
>     responsibilities.  HTTP is used for transporting server events.
>     Examples include Comet and (in some deployments) BOSH.
>
>  Out-of-band HTTP:  Here two servers are involved: bidirectionality is
>     not part of the normal HTTP/Web server responsibilities, but the
>     backend service is offered by a separate server that might not
>     even be on the same machine of the HTTP/Web server.  HTTP is used
>     for transporting server events.  When a browser is used on the
>     client side, a cross-domain solution is needed to overcome the
>     "same-source" web service restriction.  Examples include BOSH (in
>     some deployments) and Lightstreamer.
>
>  In-band non-HTTP:  Bidirectionality is part of the normal HTTP/Web
>     server responsibilities.  However, server events are transported
>     on an upgraded HTTP connection.  Examples include Bidirectional
>     Web Transfer Protocol (BWTP) and WebSockets.
>
>  Out-of-band non-HTTP:  Bidirectionality is offered by a dedicated
>     server using non HTTP protocol for transport server events.
>     Examples include WebSockets.
>
>  The HTTP transport based servers (in-band and out-of-band) can work
>  with existing HTTP standards or enhanced HTTP.  Enhanced HTTP would
>  be a standardized set of headers and behaviours to assist with
>  bidirectionality and cross domain concerns.
>
>  At present, a protocol that interacts heavily with JavaScript on the
>  client side implies some constraints also on the server side, such
>  that they have to use XML or JSON encapsulation.
>
> 6.2.  Clients
>
>  Clients can be involved in bidirectional transport in the following
>  capacities:
>
>  In browser open standards with HTTP transport:  For applications
>     written in a web browser scripting language (e.g.  JavaScript)
>     within a browser client.  Examples include Comet and BOSH.
>
>  In browser open standards with enhanced HTTP transport:  For
>     applications written in a web browser scripting language (e.g.
>     JavaScript) within a browser client.  Examples include Comet with
>     cross domain extensions.
>
>     Browsers using either standard HTTP transport or enhanced HTTP
>     transport typically use XMLHttpRequest (XHR) API
>     [W3C.WD-XMLHttpRequest2-20090820] allowing scripts to perform HTTP
>     client functionality.  The XHR object can be used to perform
>     bidirectional HTTP using both "long polling" and "HTTP streaming"
>     mechanisms.
>
>     XHR also supports the cross domain extension
>     [W3C.WD-cors-20090317], which overcomes the same-origin
>     restrictions that prevent a Web application running from one
>     origin from obtaining data retrieved from another origin.
>     However, XHR presents some limitations on the headers that can be
>     set by the user.
>
>     An alternative to XMLHttpRequest is using the Server-Sent Events
>     API [W3C.WD-eventsource-20090423].  This "EventSource: interface
>     enables servers to push data to Web pages over HTTP or using
>     dedicated server-push protocols.
>
>
>  In browser open standards with non HTTP transport:  For applications
>     written in JavaScript within a browser client.  Examples include
>     BWTP and WebSockets.
>
>  In browser with plugin:  This is not of particular interest to IETF,
>     but should be noted as part of the design space.  Examples include
>     BlazeDS.
>
>  Non-browser HTTP:  A bidirectional client may be written outside of a
>     browser and use bidirectional web transports.  Typically this is
>     done so that a rich or minimal client can bypass firewalls to
>     access public servers over HTTP transports.  Examples include the
>     Comet Java client and the Second Life Viewer.
>
>  Non browser enhanced HTTP:  [Definition and examples to follow.]
>
>  Non browser non-HTTP:  [Definition and examples to follow.]
>
> 6.3.  Intermediaries
>
>  Intermediaries (e.g. proxies, gateways, caching servers, load
>  balancers, etc) can be involved in bidirectional transport in several
>  capacities:
>
>  Legal HTTP relay:  Transports such as long polling use intermediaries
>     to carry legal HTTP requests and response.  Any capabilities that
>     may interfere with bidirectional flow (e.g. caching) are
>     controlled with standard headers or cookies.  The intermediary may
>     be a participant in the transport (e.g., changing framing or
>     encapsulation).
>
>  Defacto HTTP relay:  Some streaming transports use the common
>     behavior of HTTP intermediaries to forward content packet-by-
>     packet.  This relies on intermediaries to not cache or buffer
>     content.
>
>  Enhanced HTTP relay:  Uses yet-to-be-defined HTTP headers to assist
>     HTTP based bidirectional transports.  The intermediary may be a
>     participant in the transport (e.g., changing framing or
>     encapsulation).
>
>  Upgraded HTTP relay:  Uses HTTP upgrade to relay a non-HTTP protocol.
>
>  Tunneled relay:  Uses (or abuses?) the CONNECT mechanism to simulate
>     an SSL connection to be used as a tunnel for a non-HTTP transport.
>
>
>
>
>  [W3C.WD-XMLHttpRequest2-20090820]
>             Kesteren, A., "XMLHttpRequest Level 2", World Wide Web
>             Consortium WD WD-XMLHttpRequest2-20090820, August 2009,
>             <http://www.w3.org/TR/2009/WD-XMLHttpRequest2-20090820>.
>
>  [W3C.WD-cors-20090317]
>             Kesteren, A., "Cross-Origin Resource Sharing", World Wide
>             Web Consortium WD WD-cors-20090317, March 2009,
>             <http://www.w3.org/TR/2009/WD-cors-20090317>.
>
>  [W3C.WD-eventsource-20090423]
>             Hickson, I., "Server-Sent Events", World Wide Web
>             Consortium WD WD-eventsource-20090423, April 2009,
>             <http://www.w3.org/TR/2009/WD-eventsource-20090423>.
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>