Subject: Re: [hybi] Connection Strategy

From: John Fallows <[email-masked]>
Date: Tue, 5 May 2009 18:54:18 -0700

Greg,

You've raised some very important divergent points here that really
deserve their own thread, rather than attempting to re-purpose this
one.

Therefore, in the interests of fairness, I respectfully request that
you avoid disrupting this discussion thread which is focused on the
connection strategy for streaming and instead start a new thread for
the upcoming valuable discussion about messaging.

You seem to have some fairly strong opinions about the direction we
should be taking here, but as yet I don't have a clear and concise
understanding of your perspective.  Perhaps you could provide a
concrete proposal for the list to evaluate (in a separate thread) ?

Please realize that I personally understand that messaging is a good
thing, and I also understand that streaming is a good thing, but
trying to have both discussions at once on the same thread is not
helpful in advancing either one.

Kind Regards,
John Fallows

On Mon, May 4, 2009 at 8:51 PM, Greg Wilkins <[email-masked]> wrote:
>
> John,
>
>
> I don't mean to be disruptive to your good attempt to
> bring some order to the wide ranging discussions here....
>
> but...
>
>
> I've relabelled this phase "Message Strategy", because
> I don't think we can assume that connections are the
> starting point of this discussion.
>
>
> The references that you cite discuss origins and cross domain
> as they apply to individual resources - not connections.
> HTTP allows resources from different origins to
> be transported over the same connection (proxies).
>
>
> With HTTP, every client to server message semantically
> has it's own URL, and thus it's own origin/domain.
>
> With WebSocket, there is only a single origin/domain
> that is associated with an entire connection.
>
>
> I don't we should assume either model and should have
> a discussion about which of these (or other models)
> we prefer.  Indeed some may advocate streaming rather
> than messaging.
>
> It is a later transport discussion when we can discuss
> how messages might relate to connections etc.
>
> -------------
>
> For my contribution to messaging strategy:
>
>
>
> I advocate messaging over streaming because streamed
> data is essentially small messages at the quantum of bytes
> or bits.     The arguments for streaming and against messaging
> are essentially transport discussions about the efficiency of
> appropriate framing.  So let's defer that discussion (and if
> we have lots of 1 bytes messages, then the framing can be
> designed to match that).
>
>
> I advocate messaging over connection based abstraction
> because making connections a non-transport
> issue can be very limiting.
>
> For example, assuming a single origin per connection limits
> multiplexing and it would not be possible to offload bidirectional
> SSL to dedicated hardware that terminated all the SSL connections
> and forwarded messages to the server over fewer connections.
>
> Another example is a mashup page that contains javascript
> from multiple origins, but all of them wish to establish
> bidirectional communications with the same cross domain.
> If we assume connection semantics, then multiple connections
> will be required to the same server just to convey the
> multiple origins involved.
>
> I'm not opposed to specific transports being developed
> that do allow origin and domain to be assumed for all
> messages on a connection (and thus not have to send them),
> but that is a transport efficiency issue and not something
> that should be part of the central design of the communications
> paradygm.
>
>
>
> I agree with John that the definition of Origin should
> be adopted from his [1] reference.  This implies that
> each message has an associated URL.
>
> I think the cross domain access control referred to in
> [2] should also be closely followed where appropriate -
> although some of it is very request/response oriented.
>
> This needs to be extended to unrequested messages
> that are sent.  So for example, if every message
> from sent from a server has an associated set
> of allowed origins, then the user-agent can ensure
> that the message is not delivered to code from
> a non allowed origin.
>
> While it could be a non-trivial expense to have
> the list allowable list of origins with every
> message -  I see this as a transport concern to
> potentially find efficient way (perhaps by
> association with  a connection) to optimize this.
>
> So semantically, it is the message that has
> the allowed origins - but it may be that those
> are transported by association with a connection
> or they may be transported with per message
> meta data.
>
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> John Fallows wrote:
>> Folks,
>>
>> As promised, this "Connection Strategy" thread is the first of our
>> focused IETF discussions outlined previously.
>>
>> o Connection strategy (now)
>> o Proxy traversal strategy (next)
>> o Wire protocol (after that)
>>
>> The overall goal for this thread is to define a connection strategy
>> that can be used by future browsers for full-duplex, bidirectional
>> communication, while integrating with the browser security model.
>> This connection strategy discussion does not cover any details of the
>> specific bytes on the wire after the connection has been established,
>> and is therefore post-connection protocol agnostic.  Hopefully, the
>> connection strategy would be sufficiently general-purpose to apply
>> beyond the browser usecase as well.
>>
>> I plan to present a discussion of the requirements for the connection
>> strategy, my understanding of the available alternatives and a logical
>> conclusion based on the preceding analysis.
>>
>> The browser security model defines the trust boundary between
>> different code served by different "origin" servers.  The origin
>> concept is defined by HTML5 [1] as follows:
>>
>> "The origin of a resource and the effective script origin of a
>> resource are both either opaque identifiers or tuples consisting of a
>> scheme component, a host component, a port component, and optionally
>> extra data."
>>
>> The Cross-Origin Resource Sharing specification [2] relaxes the
>> same-origin request constraint by defining an opt-in cross-origin
>> communication strategy that uses the "Origin" HTTP header.
>>
>> The rationale for relaxing the same-origin request constraint for HTTP
>> resources applies equally well to bidirectional communication, which
>> seems well-matched by an HTTP-based "Origin" header connection
>> strategy.
>>
>> There are a number of different bidirectional communication connection
>> strategies available, such as:
>>   o crossdomain.xml + separate raw TCP connection
>>   o HTTP Upgrade in-band to raw TCP
>>   o Multiple HTTP requests representing independent upstream and downstream
>>   o Multiple HTTP requests representing overlapping upstream and
>> downstream (BOSH)
>>
>> Are there other connection strategies worth considering here?
>>
>> Note: Using a non-HTTP protocol such as XMPP or BEEP to establish
>> communication is not a separate connection strategy as it would fall
>> under crossdomain.xml with separate TCP connection.
>>
>> In-band upgrade from HTTP to raw TCP (remember discussion of specific
>> protocol bytes sent over TCP comes later) has some
>> potentially-significant security benefits over separate control and
>> data channels such as crossdomain.xml.  The concept of domain is
>> equivalent to origin but without the port, which can introduce an
>> attack vector for virtual hosting environments where different users
>> may have control over different ports.  In this case, the trust model
>> assumed by the plug-in runtime does not match the trust model enforced
>> at the server.  In-band upgrade from HTTP using "Origin" header forces
>> these trust models to match scheme, host and port.
>>
>> When an in-band HTTP Upgrade is successful, the server responds with a
>> 101 Switching Protocols status code, as specified by RFC2616, section
>> 10.1.2.
>>
>> "The server understands and is willing to comply with the client's
>> request, via the Upgrade message header field (section 14.42), for a
>> change in the application protocol being used on this connection. The
>> server will switch protocols to those defined by the response's
>> Upgrade header field immediately after the empty line which terminates
>> the 101 response.
>>
>> The protocol SHOULD be switched only when it is advantageous to do so.
>> For example, switching to a newer version of HTTP is advantageous over
>> older versions, and switching to a real-time, synchronous protocol
>> might be advantageous when delivering resources that use such
>> features."
>>
>> Using multiple different HTTP requests to provide full-duplex
>> bidirectional communication is a necessary compromise for today's
>> browser implementations, and is still subject to the HTTP 2 connection
>> limit recommended by RFC2616, section 8.1.4 Practical Considerations
>> [3].  A single post-connection TCP stream makes more efficient use of
>> the network, and gives us the most flexibility in designing the wire
>> protocol framing for future browser implementations, and seems to be
>> more general purpose for use by non-browser clients.
>>
>> In conclusion, an HTTP Upgrade with Origin header strategy seems to do
>> a good job of balancing the requirements.
>>
>> Looking forward to a fun and productive discussion.
>>
>> Kind Regards,
>> John Fallows
>>
>> [1] http://dev.w3.org/html5/spec/Overview.html#origin
>> [2] http://www.w3.org/TR/access-control/
>> [3] http://www.ietf.org/rfc/rfc2616.txt
>>
>> --
>>> |< Kaazing Corporation >|<
>> John Fallows | CTO | +1.650.960.8148
>> 888 Villa St, Ste 410 | Mountain View, CA 94041, USA
>> _______________________________________________
>> hybi mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/hybi
>
>

-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.960.8148
888 Villa St, Ste 410 | Mountain View, CA 94041, USA

---

From: Frank Salim <[email-masked]>
Date: Tue, 5 May 2009 19:22:39 -0700

Greg,

What connection strategy do you propose to use in the transport layer?

-Frank

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 06 May 2009 12:33:52 +1000

> deserve their own thread, rather than attempting to re-purpose this

Which is why I changed the subject line :)

> concrete proposal for the list to evaluate (in a separate thread) ?

I definitely have some strong opinions about what problems that
I want solved (eg browser management of connections), but I'm actually
undecided about what is the best technically and practical
solution.

Thus what I'm asking for in this thread is for people to
discuss the message vs streaming issues, as I see that as
fundamental to all further discussions.

For my own part, I can see benefits of both approaches:

For example, we could advocate a standard HTTP upgrade mechanism
that would require proxies/firewalls to support a class of streaming
protocols (kind of like CONNECT now does for SSL or TLS etc.).
Arbitrary protocols such as Websocket, BEEP, XMPP, etc, etc could all
share that upgrade mechanism and much of our work regarding
tunneling proxies/firewalls would be done.

However, I think a pure streaming solution would leave many important
issues unresolved (eg security and connection sharing).
I think that something based around messaging semantics is going to
be much better placed at resolving these issues - even if it does not
open a playing field for arbitrary protocols to compete.

I also think that a message based solution is much better placed
to build apon the experience of other standards (eg mime encapsulation,
HTTP origin security models, etc).

Thus my own current preference is a messaging based solution that aspires
to solve more of the problems that I face with my cometd work.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 06 May 2009 13:05:53 +1000

> What connection strategy do you propose to use in the transport layer?

Without the context of a specific messaging system, I'm not exactly sure
I can define a connection strategy.

Firstly we should look to the connection strategies of other
messaging based protocols and see what works and what does not
work for bidirectional communication.  HTTP and BEEP are probably
good places to start.

But broadly speaking,  I believe that connection management should be
transport issue.  Applications that send/receive messages should not
care what connection(s) were used or if those connections are shared
or not (as it is for XHR/HTTP today).

With the exception that the existence of a connection can
often be used to indicate the ability (or lack of ability)
to send/receive messages

So at an application level, perhaps there can be an abstract
conduit/channel/pipe  whose existence and state can be manipulated
and tracked by the application.  Failure of a conduit can be used
to trigger application events.

However, I do not believe that there should be a 1:1 mapping between
such a conduit and a TCP/IP connection.   That should be the job of
the transport and hidden from the application/API.

[ Note that while websocket appears to expose connections
to the application - if that was renamed conduit and decoupled
from a direct relationship to the wire protocol, then I think
the API is not far from what I'm advocating. ]

For addressing and security, I agree with John that the URI and
Origin approach look appropriate.  But we need to consider what
URI and origin mean for bidirectional non request/response communication.
One possible definition is that:

 client to server:    URI is the destination of the message.
                      Origin is of the source client code, but can't be trusted.

 server to client:    URI is the source of the message
                      Origin is the source of the message
                      Accepted-origins constrains the allowed handlers in client

This is somewhat asymmetric, but probably has to be so given
that clients are mostly not addressable (else we would have this
problem) and are not trusted.

Regardless of their exact definitions, I think that address and
origin are attributes of a message (or perhaps of an abstract conduit),
but not attributes of specific connection.

Connections need to be defined so that they can be used
for mixed addressing and origins (eg in the examples I
gave of an SSL aggregation or of mashed up widget connecting
to the same server.   But it would also be good to allow
for less complex (unshared) connections that make the optimization
for a connection carrying once conduit to assume URI and origin
(as websocket currently does).

The key thing is that the application should be unaware which
type of connection is being used.

cheers

---

From: Martin Tyler <[email-masked]>
Date: Wed, 6 May 2009 09:17:50 +0100

I can see the benefit of using a single connection for, in your example,
multiple widgets to the same server - but I can also see it complicating
what seems to be a desirable level of simplicity.

It would make server side implementations more complex, which isn't that
difficult for people like you or me Greg, implementing comet servers - but
the 12 year old coder mentioned the other week knocking up a quick WebSocket
app probably doesn't want to think about multiplexing stuff on the server
side.

There are probably reasonably trivial ways to make it optional though.

Another problem could be reconnection strategies, this needs some thought.
The client needs some involvement in this in some cases, so we'd still need
callbacks of some kind. If i remember correctly there is a 'last message id'
in the protocol (or was that something else i was looking at?) - but what if
you reconnect to a different server in a load balanced cluster? the client
might want the ability to do some resubscriptions etc.

Personally, any client or server multiplexing would be handled by libraries
so I don't have any desire for it to be built in - but I would be interested
to see a proposal for it if someone could make it suitably generic and cover
all bases.

Regards
Martin

---

From: John Fallows <[email-masked]>
Date: Wed, 6 May 2009 11:55:23 -0700

Greg,

> John Fallows wrote:
[snip]
> undecided about what is the best technically and practical

Please define the problem you expect "browser management of
connections" to solve.  For example, what do you anticipate would
break without "browser management of connections"?

> tunneling proxies/firewalls would be done.

Yes, this is an important idea, especially because it can be achieved
by clarifying existing language in the HTTP/1.1 specification only.
I'm planning to discuss this in more detail as part of the upcoming
"Proxy Traversal Strategy" thread.

> issues unresolved (eg security and connection sharing).

Even the most advanced messaging protocol with connection sharing
still needs to be able to connect before it can share.  HTTP Upgrade
does a good job of prepending HTTP-based security mechanisms in-band
with existing or future TCP-based messaging protocols that are
designed to share the connection.

> HTTP origin security models, etc).

This sounds like you are advocating we design a new general-purpose
messaging protocol with wire syntax inspired by HTTP, which implies
either HTTP/1.2 or a brand new non-HTTP protocol.  In either case, we
would still need to define a connection strategy that navigates HTTP
proxies, just like we do for the streaming scenario that enables
re-use of existing messaging protocols.

> to solve more of the problems that I face with my cometd work.

What problems do you face with your cometd work today that could not
be addressed in a future HTML5 browser by using SharedWorker [1] and
HTTP Upgrade with an existing messaging protocol like XMPP, AMQP or
STOMP?

Kind Regards,
John Fallows

[1] http://www.w3.org/TR/workers/#sharedworker
--

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 07 May 2009 23:37:32 +1000

> break without "browser management of connections"?

I believe that a browser can do a better job of managing the
secure sharing of connections between widgets, frames, tabs
and windows.

For example, to share a connection to a domain between
widgets that were loaded from several different domains
will need the browser to enforce whatever security model
is adopted.

If this connection sharing was attempted to be implemented
by a SharedWorker, then the security policy is significantly
more complex because the sharing will be performed by
downloaded code rather than trusted browser code.

> designed to share the connection.

I'm not arguing against HTTP upgrade.  I completely agree that
it is a good basis for anything that comes out of these discussions.

The question I'm asking in this thread is do we want to talk
about a message bases, stream based (or connection based)
end to end solution.

If we decide to do messaging end to end, then it opens up the
potential for us to specify and upgrade mechanism that would
allow intermediaries to understand and manipulate those messages
(eg doing aggregation, encryption, multiplexing....)

If we decide to have streams end to end, that what
intermediaries will be able to do without knowing specifics
about a stream.

> re-use of existing messaging protocols.

Actually I'm advocating that we define an end to end messaging semantic
that includes message addressing, security and content type.

If that messaging semantic is done well, applications will be able to
be developed against it and will not care what wire protocol or
how many TCP/IP connections are used.

Possible transport solutions would include Websocket style (assumed
content type, address and origin associated with unshared connection),
HTTP long polling, HTTP/1.2, something BEEP like etc.

> HTTP Upgrade with an existing messaging protocol like XMPP, AMQP or

Secure sharing of limited resources (connections).  I don't
see how a sharedworkers can be a secure broker of messages
from differing origins.

Browsers do an excellent job of secure sharing, pooling, idling,
recycling, retrying, caching, pipeling and proxying HTTP
connections for most normal HTTP usage.  HTTP Long polling
is now stressing this model, but I don't think the solution
should be to make the application responsible for connection
management.

To invert the question to you.  What are the drivers
that you see for the connection state to be exposed to
the application?

regards

---

From: John Fallows <[email-masked]>
Date: Thu, 7 May 2009 18:23:31 -0700

> downloaded code rather than trusted browser code.

There are lots of deployed applications, including desktop, mobile and
browser plug-in based that do not have a recommended limit on the
number of raw TCP connections.

There are IETF-recommended connection limitations for HTTP over TCP
that were created for reasons that may not be as relevant in today's
world of streaming HD video over the Internet, as Roy put it.

IMHO, the projection of the HTTP over TCP connection limitation
requirement onto Web-friendly real-time bidirectional connectivity
falls into one of 2 categories:
  a) having many TCP connections is not a problem in practice (yet), or
  b) having many TCP connections is a problem with TCP not HTTP.

If the answer is a) then a stream abstraction that maps to HTTP
Upgrade provides flexibility of protocol choice at both client and
server, and intermediaries can opt-in when they have a first-class
understanding of the Upgrade protocol.  This ability to opt-in is
predicated on the intermediaries understanding of the protocol name in
the Upgrade header.  IANA would likely be a suitable standards
organization to define such a registry.

If the answer is b) then the most straightforward solution would be to
define "multiplexed streams" over TCP because that avoids having to
remap higher layers that already understand how to build on top of a
TCP stream abstraction.

One major problem with "multiplexed streams" over TCP is "head-of-line
blocking" which prevents delivery of chunks within independent
streams.

To clarify, if the TCP stream sent by the server looks effectively like this:

TCP/IP Packet #1 [Logical Stream A Packet #1]
TCP/IP Packet #2 [Logical Stream B Packet #1]
TCP/IP Packet #3 [Logical Stream A Packet #2]
TCP/IP Packet #4 [Logical Stream A Packet #3]
TCP/IP Packet #5 [Logical Stream B Packet #2]

Then loss and retransmission of Logical Stream B Packet #1 (which is
at head-of-line) blocks delivery of Logical Stream A Packets #2 and #3
even though these packets may have already arrived, awaiting
reassembly in the receiving TCP buffer.

Multiplexing streams over a different protocol peer of TCP and UDP,
such as SST [1], DCCP [2] or SCTP [3] has the potential to maintain
the congestion control benefits of TCP while eliminating the
head-of-line blocking issue without invalidating how existing
protocols are defined to map to a byte stream.

In practice, defining such a stream multiplexing protocol over UDP
instead has a much reduced impact on globally deployed IP
infrastructure.  Perhaps there is an opportunity here for progressive
enhancement over time.

Note: The Flash 10 runtime includes RTMFP [4], which is a proprietary
UDP-based protocol for peer-to-peer connectivity that relies on UDP
hole-punching [5] through firewalls coordinated by a server, similar
to Skype.

> it is a good basis for anything that comes out of these discussions.

Good.

Revising the HTTP/1.1 specification to provide clarification of proxy
behavior for HTTP Upgrade has definite value.

> intermediaries will be able to do without knowing specifics

All of the goals you cite above for a message based solution over TCP
can be addressed more generally and with fewer implementation
constraints by multiplexed byte streams and standard HTTP Upgrade
protocol names.

> HTTP long polling, HTTP/1.2, something BEEP like etc.

It sounds like you are suggesting we standardize a high-level
messaging API like Java Messaging System (JMS) with a pluggable
transport system, similar to what you have done with Bayeux.

As I understand it, the IETF standardizes protocols, including the
wire syntax and operational semantics of those protocols, but not APIs
or abstract, protocol-independent semantics.

Btw, a subtle but important point - the WebSocket specification
defines how it maps to a stream of bytes, which may be a multiplexed
stream of bytes over a shared TCP connection, or it may map directly
to a physical TCP connection.

> should be to make the application responsible for connection

Understood. However making the leap to a message based solution might
be considered unnecessary.

> that you see for the connection state to be exposed to

Our customer base is extremely enthusiastic about extending the reach
and full feature set of their server-side TCP-based protocols to the
browser.  In many cases, they have invented custom protocols used
either by intranet-deployed plug-in technology clients or desktop
clients.

Deploying these or similar applications to the Web always hits a road
block of how to map efficiently to HTTP, as well as the undesirable
implementation effort involved at the Web server to hand-code, debug
and support that mapping, typically resulting in the browser
application being a poor second cousin to the desktop application.

They are looking for the same freedom at the browser client that they
currently enjoy for desktops and servers - namely that the lowest
common denominator is a Socket, which is why they are encouraged by
the arrival of an equivalent concept for Web browsers that can
successfully navigate the HTTP infrastructure of the Web.

Kind Regards,
John Fallows

[1] http://pdos.csail.mit.edu/uia/sst/
[2] http://en.wikipedia.org/wiki/Datagram_Congestion_Control_Protocol
[3] http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol
[4] http://en.wikipedia.org/wiki/Real_Time_Media_Flow_Protocol
[5] http://en.wikipedia.org/wiki/UDP_hole_punching

--

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 08 May 2009 12:50:42 +1000

> world of streaming HD video over the Internet, as Roy put it.

As the implementer of a HTTP server, I can definitely say that
limiting HTTP connections is still a significant concern.

With mashups, portlets and widgets, it is easily conceivable
for a web page to have 10's if not 100's of logical connections
to the server.   If we come up with a solution that insist
that each of these is given a dedicated TCP/IP connection,
then there are significant scaling issues at the server side.

We typically would like a server to be able to support
10's of thousands of simultaneous users. If each user needs
10's or hundreds of TCP/IP connections, then we are looking
at approaching a million connections per server!  It only
get's worse for a load balancer!

> blocking" which prevents delivery of chunks within independent

Indeed.  There are many difficulties and complexities with multi-plexing

I do not think multi-plexing should be mandatory in any solution and
that simple 1 TCP/IP for 1 use solutions should be available and perhaps
even the norm.

But what I'm saying, is let's not design out the possibility
of multi-plexing by promising a TCP/IP connection in the
application API/contract.

> transport system, similar to what you have done with Bayeux.

Not at all.

Currently I would call the current WebSocket API a mix of
message based (onmessage, postMessage) and of connection
based (onopen, onclose, disconnect).

I think these are just about right, but that they are
concerns need to be separated and disassociated from
a specific transport.

Applications will mostly be concerned with postMessage
and onmessage.     Currently websocket associates a URI
and origin with the instance of the Websocket.    I think
that is OK - so long as the websocket represents a logical
connection (I call them conduits) that may be multiplexed.
Currently it represents a real TCP/IP connection with a
definite wire protocol that cannot be multiplexed.

The onopen, onclose connection semantics are also important,
as they can be used to trigger business logic about the
ability or lack of ability to send/receive messages.
But again, this should be abstracted from the association
with a TCP/IP connection.

Initial implementations of such a decoupled API could
be a simple 1:1 mapping to TCP/IP sockets.   But importantly,
by not making the promise that a websocket == TCP/IPsocket, this
allows browsers (or ideally even javascript frameworks)
to implement the conduits with multiplexed connections
if they so wished.

For example, it would be great if a framework could
implement their own sharedworker that could intercept
all conduit creations and manage the multiplexing and
sharing of real connections.

This could also be done by the browser (for cross
domain solutions).

> or abstract, protocol-independent semantics.

Well while I've discussed it from an API point of view above,
I'm really concerned only about the semantics and not the API
(and would be happy if there was a pure messaging API with a URI
and meta data for every send).

Conversely - I find it strange that the websocket API is
attempting to specify how IETF standards should specify
connection management of protocols.

> to a physical TCP connection.

hmmmm now that would be framing (websocket) over framing(multiplexed
stream) over framing (TCP/IP packets).

That seams a little over complex.

I've already posted a suggestion for the websocket wire protocol
that would define a frame type for mime encoded messages.
Such a frame type could easily be used to support a large
number of different multiplexing schemes and other
useful things (eg gzip compression of datagrams).

> be considered unnecessary.

But websocket is already message based?

> successfully navigate the HTTP infrastructure of the Web.

But if these needs can be met by the current datagrams
of websocket, why can they not be met by similar datagrams
that are associated with an abstract conduit rather than
a definite TCP/IP socket?

I really don't think we are advocating positions that far
apart.    You are proposing multi-plexed streams to carry
multiple websocket connections.     I'm proposing that perhaps
the websocket framing can be mildly extended so that it
can handle both a non-multiplexed connection or a multiplexed
one.

regards

---

From: John Fallows <[email-masked]>
Date: Fri, 8 May 2009 02:03:37 -0700

> limiting HTTP connections is still a significant concern.

I'm assuming you meant that _unlimited_ HTTP connections is still a
significant concern - please let me know if I misinterpreted.

Given that HTTP is layered over TCP, which in turn is layered over IP,
there's really no such thing as an HTTP connection, only HTTP traffic
over TCP connections.

If you trace the IP layer wire traffic to compare 10 pipelined HTTP
requests over a single TCP connection versus the same 10 HTTP requests
over 10 TCP connections, then the difference in IP traffic is entirely
caused by the differences at the TCP layer.

Therefore, if there is an issue with having many TCP connections at
the transport layer underneath HTTP, then that problem can be
addressed at the transport layer by providing alternative transport
strategies that maintain the reliable bidirectional byte stream
required by HTTP.

For example, HTTP can operate without any wire syntax changes over a
bidirectional stream in an SCTP association because it maintains the
Socket abstraction providing a reliable bidirectional byte stream.

> then there are significant scaling issues at the server side.

The mashups, portlets and widgets are at such a high level of
abstraction compared to the transport layer (such as TCP/IP) that
there is plenty of opportunity to coordinate in between.

For example, simple stream multiplexing would probably be sufficient
to address TCP connection reuse, but one could also leverage a more
advanced messaging protocol, like AMQP, to act as a message bus shared
by mashups, portlets and widgets displaying data from the same origin.

The display widgets would likely have a pluggable data model, making
AMQP just one example of providing bidirectional data access and
update notification.

> get's worse for a load balancer!

Developing a Web application that requires 10's or hundreds of
distinct physical TCP/IP connections demonstrates a poor use of
abstraction.  As I said above, there are plenty of opportunities in
the Web application design to solve this more effectively.

The ability of the application to work properly directly affects its
popularity, so even the undesirable scenario of having a
500-connection Web application is entirely self-healing.

> Indeed.  There are many difficulties and complexities with multi-plexing

What other difficulties and complexities are you referring to?

> application API/contract.

A reliable bidirectional byte stream contract is sufficient to provide
different transport possibilities, and assuming TCP/IP to begin with
is appropriate.

For example, your favorite TCP-based protocols, like HTTP, FTP, IRC,
AMQP, XMPP, all still work when multiplexed over a single TCP-based
VPN, even though none of those protocols were designed with the VPN
multiplexing protocol in mind.

> definite wire protocol that cannot be multiplexed.

This is incorrect.  WebSocket wire protocol represents a reliable
bidirectional stream of frames (binary or text content) that _can_
easily be multiplexed.

For example, WebSocket wire protocol can operate with unmodified wire
syntax over one of many bidirectional streams in a shared SCTP
association.

> with a TCP/IP connection.

The bidirectional stream of (text) frames exposed by the (JavaScript)
WebSocket API is opened and closed, not necessarily the TCP/IP
connection.

> to implement the conduits with multiplexed connections

That's right.

> sharing of real connections.

Yes, there is plenty of opportunity for innovation here.

> This could also be done by the browser (for cross

Yes, although in practice the intersection of server DNS names and IP
addresses is potentially quite small, so the dominant cross-domain
use-case is more likely to be for intercepting proxies.

> and meta data for every send).

Unfortunately, starting with the API semantics adds confusion because
it focuses us on a discussion about which layer of the client
networking stack should be exposed to JavaScript rather than how the
browser as a whole interacts with the network.  As I understand it,
the IETF is much more concerned with the latter, while the W3C is
responsible for selecting an appropriate JavaScript API for developers
to use.

> connection management of protocols.

I think you might have misunderstood the subtle but important point
explained below.

> That seams a little over complex.

This is just the networking 101 concept of layering, where each layer
depends on the layer below.  The primary benefit is to provide an
abstraction where lower layers can be entirely replaced, impacting
only the single layer directly above, while all other layers above
that remain unchanged.

Bear in mind that we haven't had the "Wire Protocol" discussion thread
yet which might impact the WebSocket protocol text vs. binary framing
syntax.

> But websocket is already message based?

As mentioned above, WebSocket wire protocol is a stream of frames
(text or binary), whereas the WebSocket API is defined to send and
receive only text frames using WebSocket.postMessage() and
WebSocket.onmessage.

Solving the (TCP) multiplexing problem by mixing in aspects of the
(HTTP) protocol running over TCP might be considered a leap that
unnecessarily violates the abstractions provided by the networking
layers.

> a definite TCP/IP socket?

These needs can be met by the currently defined stream of text or
binary frames provided by WebSocket without implying the underlying
network transport in use, although TCP/IP is a reasonable default.

> can handle both a non-multiplexed connection or a multiplexed

Yes, I believe we are starting to think about the problem in a more
similar way.  Now we just need to determine the most appropriate
networking layer to apply some of the remaining design constraints.

Kind Regards,
John Fallows
--

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 09 May 2009 13:26:51 +1000

John,

I'm not making up a hypothetical problem.

The number of TCP/IP connections that servers must
terminate *is* already an issue for many using normal
 HTTP long polling

While there is indeed little difference in what is sent
over the wire, there is a differences in the resources
allocated at the server side.  There are kernel data
structures and buffers allocated per connection.

Modern operating systems do a great job of
handling large numbers of TCP/IP connections, but
I do not see that as a reason to unnecessarily
create a situation where an order of magnitude
increase in requirements is possible.

The multiplexing we are talking about is to route
messages to/from various applications components within
the browser process from/to various application components
within the server process.     TCP/IP provides the process to
process addressing and delivery, but to use it to
perform the fine grained routing within each process
strikes to me as mis-appropriation of kernel resources.

You say that websocket wire protocol is easily
multiplexed - but only with SCTP style sockets (more
kernel resources) or with cooperative applications.

> there is plenty of opportunity to coordinate in between.

Only if we provide the right abstraction that they can
code against.    The current websocket API certainly
does not allow for an SPI or any interception that can
be done by frameworks and/or sharedworkers.

Many web applications are not centrally designed, but are
integrations of the work of many developers.   Portal sites
such as iGoogle allow users to plugin gadgets from 3rd
parties.    In such an environment, it is very hard to
impose a top level design unless there are some good
common abstractions that they are all build on.

Thus it is very important that we establish these
abstractions before progressing the discussion.

To this end rather than pointing out what else
I disagree with in your response, let me highlight
the common ground

> WebSocket wire protocol represents a reliable
> bidirectional stream of frames (binary or text content) 
> ....

Excellent!

However, I think the spec needs to more clearly state this
separation of concerns, but hopefully that will come out of
this process.

[ I also think websocket would benefit from perhaps
defining an SPI so that frameworks and browsers could
implement behaviour below the API level... this could be
used to map the API to a HTTP long poll transport while
waiting for wire protocol support! but that's
not off-topic for here ]

So I think that we agree that the solution we want
will be based on a frame abstraction (what I called
messages), that are abstracted away from any transport.

Do others agree with this as a basis?

Now I think you go further and are advocating
(correct me if I'm wrong) that these frames
be organized into streams and that meta-data (eg
URI and origin) are associated with the stream
rather than the frame.

I agree that this is a good model for many
webapps and allows for both simple application
development and some trivial wire protocol
implementations.

However, I don't agree that this is the only
abstraction that should be supported.

I would like to see optional meta data associated
with each frame. Per frame meta data will allow
the transport of alternative content types (building
on existing mime experience) and will well support
a variety multiplexing solutions.

Thus the abstraction I'd like to see, is one where
meta data can optionally be set on each frame. If
there is no meta data set on an individual frame, then
the meta data for the stream will apply.

This approach would appear to well support both
our points of view.

regards

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Sat, 09 May 2009 10:09:43 +0200

> increase in requirements is possible.

What happens when the socket is terminated because one component is not 
behaving fairly? Every other components would suffer from it?

> strikes to me as mis-appropriation of kernel resources.

I don't quite see how. Isn't IP+port the right way of doing routing? 
Clients will talk to an application server with a well known protocol 
(XMPP for instance) on a given port. Whether that client lives in a 
browser makes little difference to the routing mechanism, doesn't it?

I wouldn't be surprised if due to complexity in multiplexing we end up 
with reverse proxy on the server side (ala mod_proxy, e.g. mod_ws_proxy) 
that would forward any incoming data to the appropriate application 
server, thus not reducing the amount of resources required.

- Sylvain

---

From: Martin Tyler <[email-masked]>
Date: Sat, 9 May 2009 09:59:27 +0100

Sorry for not quoting, it's getting a bit out of order :)

The multiplexing stuff.. I made a comment a few days ago which I don't think
was responded to...

Carrying multiple 'channels' over one socket to maybe allow multiple client
widgets talking to the same server to use the same socket means more
complexity on the server side. Without some kind of common server API for
people to write to this would be prohibitive to people writing simple
WebSocket servers as described a few weeks ago (12 year olds)

The use case mentioned, a number of widgets on a single page... if they are
talking to the same server I would think it is likely that they can use a
client side api to manage the multiplexing. If the widgets are truly totally
separate pieces of software written by different people how likely is it
that they will be talking to the same server?

Maybe we should go into more detail on the use case for
channels/multiplexing being built in? At the moment I cannot see the
scenario where a library on top of websocket couldnt do the job better

Regards
Martin

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 11 May 2009 09:13:13 +1000

Martin Tyler wrote:

> The use case mentioned, a number of widgets on a single page... if they
> are talking to the same server I would think it is likely that they can
> use a client side api to manage the multiplexing. If the widgets are
> truly totally separate pieces of software written by different people
> how likely is it that they will be talking to the same server?

Consider google and who have the igoogle portal page which allows
third party gadgets to be plugged into the page. They also have a
WS API that those gadgets can currently make ajax requests to, when
they do this, the gadgets share the connection pool from the
browser to the google servers.

If google started providing a comet API on their servers, then all
of a sudden, these 3rd party gadgets would each be having their
own connection and doing their own connection management.

Note also, I don't think we can use the non-existence of a style
of webapp today as evidence that it will not be done in the
future.  Perhaps they do not exist today because it is
simply too hard to do - and that the existence of a better
communications abstraction will make all sorts of new web applications
possible.

> scenario where a library on top of websocket couldnt do the job better

How could a library on top of websocket enforce orgin based security?

How could a library on top of websocket implement a connection sharing
policy for a 3rd pary component written directly to the websocket API?

regards

---

From: Ian Hickson <[email-masked]>
Date: Sun, 10 May 2009 23:17:46 +0000 (UTC)

On Mon, 11 May 2009, Greg Wilkins wrote:
> 
> Consider google and who have the igoogle portal page which allows third 
> party gadgets to be plugged into the page. They also have a WS API that 
> those gadgets can currently make ajax requests to, when they do this, 
> the gadgets share the connection pool from the browser to the google 
> servers.
> 
> If google started providing a comet API on their servers, then all of a 
> sudden, these 3rd party gadgets would each be having their own 
> connection and doing their own connection management.

If we (Google) were to provide an API like this, we would provide an API 
that coallesced the messages into one stream. We wouldn't have each gadget 
opening up their own connection.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 11 May 2009 10:25:41 +1000

> I don't quite see how. Isn't IP+port the right way of doing routing?

HTTP and whatever protocol we are discussing here are
application layer protocols.  IP+port are a transport
address:

 * IP address is a network layer address and identifies a host

 * port is a transport layer concept and identifies a
   service/process == application

 * application layer protocols (eg HTTP) uses
   addition information (eg URI) to identify resources
   within a given service/process/application.

Thus in good layered networking  a socket is
identified by src IP + src port + dest IP + dest port
and represents a connection between applications.

Applications layers should not use a transport
address to identify application resources.  If
they were to do that, then:

 + HTTP would use connection per resource (ok HTTP/0.9 did that!)
 + POP/IMAP would use connection per email
 + X-windows would use a connection per window
 + XMPP would use a connection per conversation
 + BEEP would use a connection per channel
 + Telnet would open a new connection for every command run
 + FTP would use a connection per file (DOH! it does do this, but
   historically it has been a PITA that it does so.  It is
   the exception that proves the rule!)

HTTP/0.9 was indeed a lot simpler to implement than HTTP/1.1
none of those content-length, chunking and pipelining concerns.

If we wanted the efficiency of multiple resources from a
server - the IETF could have said that applications should
use higher level constructs to put multiple resources into
a single connection (eg use multi-part mime).   But that
never happened, because transport sharing is an
application layer concern - not an application concern.

Instead HTTP/1.0 keep-alive and then HTTP/1.1 were developed
to include features that allow a single transport connection
to serve multiple resources.

To argue against supporting multiple resources in bidirectional
communications is paramount to saying that we should go back to
HTTP/0.9 and allow applications develop higher level protocols
(eg multi-part mime) to send back a web page and all it's
resources over a single connection.

Transport sharing should be done in the application layer
protocol and not in the application!

> behaving fairly? Every other components would suffer from it?

I don't see how/why one component would be allowed to terminate a
shared connection - no matter how badly it behaves.

But even if it does, then the connection management software
can re-establish a connection and other state with it.

HTTP clients already do this! They have a pool of connections
to the server - any of which may close at any time for several
good/bad reasons.  The HTTP clients know how to recreate connections
and what requests can be resent and which cannot.

This is a good example of how the application layer protocol
can handle complexities of transient transport failures with
minimal intervention of the application itself.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 11 May 2009 10:57:44 +1000

> opening up their own connection.

Ian

If this was a perfect world and all of us were perfect developers - maybe !
But that is just not how WS software get's developed, deployed and
evolved.

It is the *ENTIRE POINT* of open standard based web service that you
don't have to provide code to the client so that they can access
your services.  You just want to define a restful, SOAP and/or XML-RPC
interface to your service and let the 3rd parties decide if they
want to use jquery, dojo, prototype, java, C#, whatever to talk to it.

I'm acme.com,  I write a cool service for my own web site, using googles
WS apis.  I write my javascript to call those WS apis - but without using
any google JS - i use dojo or jquery to wrap XHR to talk directly to google.

I now decide that I want to wrap up that cool service as a google gadget
for the igoogle page.     I don't want to rewrite the WS code - because it
works fine.  So I put the WS code into the gadget and it talks directly
to the google WS's      Currently because it is based on XHR, the browser
deals with it and shares the HTTP connections with other gadgets for me.

Even if google did provide a javascript library on top of XHR for
some special connection sharing - they have no means to enforce that my
gadget uses it.  Plus they might have licensing restrictions that prevent
me using it on my own website - so I can't use it for both deployments
of my cool service.

But let's say I  did decide to use googles connection sharing library
for my acme.com gadget.   But then my competitor badass.com develops a
gadget that deliberately bypasses the library on the belief that using
their own dedicated connection would give their gadget some performance
gain.  This might even work for a time, at least until I update the
acme.com gadget to do the same thing. Then everybody would have the same
performance,  but the server would have more sockets to deal with and
the network would have less flow/congestion control.   A great lose lose
situation for no gain.

Voluntary sharing of resources is all fine and well, until one
self interested party puts self interest above the collective
good.    I don't know what world you live in, but mine is full
of self interested developers!

regards

---

From: Martin Tyler <[email-masked]>
Date: Mon, 11 May 2009 09:21:00 +0100

> want to use jquery, dojo, prototype, java, C#, whatever to talk to it.

But if we are multiplexing 'channels' you cant just define a resful/whatever
service, as the server has to multiplex the difference services - which is,
as i touched on before, ok if you use a well developed server which does
that multiplexing for you (exposing a possibly non-standard new interface on
the server?)

i'm not totally against the channels idea, but the server side needs some
thought here too. I've been out of touch for a while, has there been any
work at all in the server side of this in general rather than channels
stuff, eg servlet api or anything else?

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 11 May 2009 20:38:04 +1000

Martin Tyler wrote:
> 
> 
> On Mon, May 11, 2009 at 1:57 AM, Greg Wilkins <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> But if we are multiplexing 'channels' you cant just define a
> resful/whatever service, as the server has to multiplex the difference
> services.

Martin,

I don't understand your point.  Can you explain some more?

To expand on my thoughts on this matter, consider if the google
server provides several cometd services at the following URIs

  /gcomet/newsAlerts
  /gcomet/stockPrices
  /gcomet/twitters

A simple client could open a HTTP connection to any of those
URIs and upgrade to to the bidirectional protocol.  Each connection
would then be associated with a single URI and datagrams
sent/received would be to/from that URI and they could be
framed without any meta data. 3 connections would
be used to connect to all 3 feeds.

But a more sophisticated client could connect to /gcomet
and upgrade to the bidirectional protocol.  It could then
send some control datagrams (using meta data associated
with the datagrams to indicate they are control messages)
which registered interest in the 3 URIs.   Datagrams
could be sent/received over that connection, but each would
need to have associated meta-data to indicate which of
the URIs the message was to/from.

regards

---

From: Martin Tyler <[email-masked]>
Date: Mon, 11 May 2009 11:58:05 +0100

> the URIs the message was to/from.
I am thinking of the server side implementations of these services. If they
are, for example, developed by different developers/teams it would be hard
to do that in isolation from each other without something on the server
handling these meta data messages and routing the data to the write server
side component. This dispatching of messages to the right service would need
an API or server side development is not going to be very modular.

You are suggesting the browser does the equivalent on the client side, which
fits well and as you point out means widget developers don't have to worry
too much about it or make sure they use the correct wrapper libraries etc.
However, on the server side there is a lot more software around, a lot more
custom implementations - some of which have APIs for existing things of
course, CGI, servlets etc, and they would need to handle this multiplexing.

So in your example, someone needs to be able to implement the
/gcomet/stockPrices server service without knowing that there is a
/gcomet/twitters service and that a client might be accessing
/gcomet/stockPrices via a common /gcomet connection

---

From: "Sylvain Hellegouarch" <[email-masked]>
Date: Mon, 11 May 2009 14:00:11 +0200 (CEST)

> protocol and not in the application!

I think we misunderstood each other in regards to what I mean by routing.
I'm not convinced sharing one single connection for several distinct
services (XMPP, HTTP, BEEP, etc.) is the right idea because it adds, I
think, complexity to what already exist with TCP: IP+Port.

Now for one given service, I can understand why you would share the
connection to access, as you call it, distinct resources.

> can re-establish a connection and other state with it.

Well I'd expect so for sure. My problem is not about what to do upon
disconnection, it's with the fact that one component may break the flow of
others. That's rather expensive to me from a user experience perspective.

Cheers,
- Sylvain
-- 
Sylvain Hellegouarch
http://www.defuze.org

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 May 2009 00:43:30 +1000

> think, complexity to what already exist with TCP: IP+Port.

Totally agree!

thanks for the clarification.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 May 2009 00:52:56 +1000

Martin Tyler wrote:

> I am thinking of the server side implementations of these services. If
> they are, for example, developed by different developers/teams it would
> be hard to do that in isolation from each other without something on the
> server handling these meta data messages and routing the data to the
> write server side component. This dispatching of messages to the right
> service would need an API or server side development is not going to be
> very modular.

Why can't it be modular?

Servers already map HTTP requests to resources (Servlets in the case
of Java) in a modular fashion.

> You are suggesting the browser does the equivalent on the client side,
> which fits well and as you point out means widget developers don't have
> to worry too much about it or make sure they use the correct wrapper
> libraries etc. However, on the server side there is a lot more software
> around, a lot more custom implementations - some of which have APIs for
> existing things of course, CGI, servlets etc, and they would need to
> handle this multiplexing.

Which is why I think the protocol we are working towards (let's call it HYBI
for HYpothetical BIdirectional protocol) needs to support multiplexing
in the standard.

The server implementors like myself would implement the HYBI
protocol so that I can send/receive datagrams to/from modular
application components.    Initially this would probably be
via proprietary API's, but in java at least, I would expect
a standard API to rapidly be developed as a JSR.

This would be no different to how I would proceed on the
server if WebSocket was ratified in it's current form.
The server would still need to terminate the websocket
connection and manage the routing of datagrams to/from
modular application logic.

The only real difference is that with websocket as it is,
the URI would be constant for a connection, while
with HYBI there could be a new URI for each datagram.

> /gcomet/stockPrices via a common /gcomet connection

I imagine that the API will be somewhat like servlets
and a modular application logic can be mapped to URIs.

cheers

---

From: Martin Tyler <[email-masked]>
Date: Mon, 11 May 2009 16:08:36 +0100

> of Java) in a modular fashion.

exactly - you need the servlet API to do this for you, all I am saying is
WebSocket (or whatever) needs an API on the server if it is to support a
decent development model - especially if a channel paradigm is added to the
design.

> and a modular application logic can be mapped to URIs.

Ok, looks like we agree really - you misunderstood my comments. I am (was)
saying that the current WebSocket design does not prescribe any kind of
server API at all - but if we baked in channels, you would need to have an
API or server components could not easily be developed in a modular fashion.

What I am getting at is that we should be discussing this server API - this
would be a good idea anyway, but the channels idea makes it even more
important imho.

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 12 May 2009 01:25:57 +1000

Martin Tyler wrote:
> Ok, looks like we agree really - you misunderstood my comments. 

Excellent - (not that we misunderstood each other, but that we got
to understanding in the end :)

> I am
> (was) saying that the current WebSocket design does not prescribe any
> kind of server API at all - but if we baked in channels, you would need
> to have an API or server components could not easily be developed in a
> modular fashion.

I kind of agree.  But I'd say it in terms of defining the
server side semantics rather that API.   API styles can
differ greatly due to language, environment and taste.

> What I am getting at is that we should be discussing this server API -
> this would be a good idea anyway, but the channels idea makes it even
> more important imho.

Indeed - and not just the addressing and handling of datagrams, but
the application of security, origins, allowed xd origins etc needs
to be considered.

cheers

---

From: Lisa Dusseault <[email-masked]>
Date: Sun, 17 May 2009 15:51:37 -0700

Since we're discussing characteristics at this high level, I hope this
group is roughly familiar with SCTP as a contrast:
http://tools.ietf.org/html/rfc4960

SCTP can replace TCP, providing transport  with better characteristics
for HTTP, including built-in multi-streaming and respect for message
boundaries.

Lisa

---

From: Greg Wilkins <[email-masked]>
Date: Mon, 18 May 2009 09:58:04 +1000

> for HTTP, including built-in multi-streaming and respect for message

Lisa,

I'm indeed roughly familiar with the concepts and features offered
by STCP and it would appear that it would have a lot to offer
bidirectional transports of the type we are after.

However, I'm unfamiliar with the advocacy, support, likely
penetration and timescale of STCP.    Is there anybody that can
offer a view on these subjects?   ie is STCP a prospect for
the near, mid or long term?

cheers

---

From: Pieter Hintjens <[email-masked]>
Date: Mon, 18 May 2009 10:26:50 +0200

> the near, mid or long term?

It's SCTP (streaming control transmission protocol), not STCP.  Easy
mistake to make...

For what it's worth, my team studied the use of SCTP for AMQP[1], a
messaging protocol we work on.

To some extent SCTP solves many of the problems of the AMQP transport
layer such as automatically reconnecting channels, multiplexing, and
so on.  It is trivial to use SCTP in place of TCP through the socket
interface, and we have done this for our open source AMQP messaging
produce, OpenAMQ[2].

SCTP is not universally available and not widely known, but does look
like a compelling upgrade to TCP.  However that would be meaningful
only if SCTP was a plug-and-play replacement.  If higher-level
protocols need to change in order to use SCTP, it will never IMO be
used.

So you can consider SCTP as a kind of enterprise TCP.  This means you
can move certain features out of whatever protocol sits on top of TCP.
 For example, connection multiplexing, which we did in AMQP, is in
fact redundant because users that need it can use SCTP.

Hope this helps.

-Pieter Hintjens
iMatix

[1] http://www.amqp.org
[2] http://www.openamq.org
[3] http://www.restms.org