[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [amqp-bindmap] Re: [amqp-ms] RE: [amqp] Re: [amqp-bindmap] Raw notes from AMQP Redmond workshop
|
To be clear, there are no changes to the core spec implied by the mapping to WebSockets.
The proposal to map an AMQP Frame to a WebSocket message means that there is no need to alter frame size negotiation – the AMQP Frame size and WebSocket frame
size are independent (if the AMQP frame is bigger than a WebSocket frame, continuation frames are used). The only implication is that at an AMQP Frame boundary one must start a new WebSocket message (and thus a new WebSocket frame). This is obviously trivial
to implement. In the browser this means that one onMessage will contain exactly one AMQP frame which removes the need to replicate the buffer concatenation and frame parsing which WebSockets can do for you. It took me about half an hour to implement a TCP
<-> WebSocket gateway based on this scheme. -- Rob From: amqp-bindmap@lists.oasis-open.org [mailto:amqp-bindmap@lists.oasis-open.org]
On Behalf Of Raphael Cohn Dave, Thank for the reply. I'm a bit confused as to what you're actually proposing now, but I'm happy to wait until the call to discuss things in more detail. For me, a websocket message IS a set of websocket frames (binary+continuation). The
websockets API in the browsers raises one onMessage callback per complete websocket message received. At my end, I've built a complete websockets binding and a trivial AMQP js client (ie just enough to understand the problem space). I see absolutely no reason to do anything at all to AMQP to work with WebSockets. We simply use it as a transport
wrapper. Frame size negotiation does not need to change at all. This means onMessage will contain one, several, part of one, or several and part of one, AMQP frame (or handshake). Not a problem, Just concatenate the array buffer in the client code. Far bigger
fish to fry - like state management or decoding... Indeed, it is essential to not change the main spec, because otherwise, we exclude EVERYONE who wants to just put a simple Websockets TCP gateway in front of an AMQP connection - no matter from whom they are getting that AMQP connection.
Instead, we bias the market to favour only:- - bespoke WebSockets vendors - those broker vendors who support this variation In other words, it could be seen as anti-competitive and not in our customer audience's best interests. Raph PS Having implemented WebSockets, I'm very unimpressed by the WebSockets RFC. It can't make its mind up if its a transport protocol or an application protocol.
Raphael Cohn Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard +44 7590 675 756
On 18 April 2013 06:00, David Ingham <David.Ingham@microsoft.com> wrote: Moving member section and core TC to BCC as this is a bindmap topic. Hi Raph, We considered mapping AMQP frames to Websocket frames but ruled it out primarily because different hops in a multi-hop Websocket chain could use different frame sizes. For example, an intermediary may read a Websocket message that is split
over two frames and send it on re-encoded in to 1 frame or 3 frames. Because of this there’s no way to know what AMQP frame size should be negotiated to ensure that it could safely be transmitted in a single Websocket frame. We took advice on this from several
folks who worked on the spec and they all made the same recommendation that we should map AMQP frames to Websocket messages. All - I’ve sent out a meeting request for a Websockets discussion next Wednesday at 9am Pacific time. I’ve only included those folks that I know are interested in contributing to the spec. If you don’t see the invite but would like to
attend then ping me. For those of you interested in reviewing the resultant spec, hang on a while, we’ll have a dedicated review when we have agreement on direction between the authors. Thanks, -----Original Message----- Dave, Thankyou. Regarding websockets, I'm very worried that you want to map AMQP frames to websocket frames. This makes it impossible for anyone to then use one of the many tcp to websocket gateways, so reducing interoperability, and requiring
deep broker integrations, etc. In some ways this point mirrors the discussion we had about TLS in AMQP. It does slightly complicate writing a js client, but very very slightly (one has to hold onto the last few bytes in a buffer and append them to the next
buffet). Frankly, given that it's very hard to write a js client in any event, this is exceedingly minor. Raphael Cohn Chief Architect StormMQ Limited UK Office: Gateshead int'l Business Centre, Mulgrave Terrace, Gateshead, NE8 1AN, United Kingdom Telephone:
+44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 18 Apr 2013, at 00:09, David Ingham <David.Ingham@microsoft.com> wrote: > A few folks have asked me for my notes from the Redmond workshop that was held back in February so here they are attached. They are a little raw I'm afraid. There is reference to the AMQP management spec in these notes. Rob Godfrey,
Rob Dolin and I have been iterating on that quite a bit since the workshop and I suspect that we'll have something to distribute for review within the next couple of weeks. > > Thanks, > Dave. > <mime-attachment> > <2013.02-AMQP-TechnicalWorkshop-Redmond-Notes-Public.pdf> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]