[hybi] (no subject)

[Hapner mark <[e-mail]>]

Hi Martin,

Thanks for the feedback, See comments below ...

-- Mark

 >Hi Mark,
 >
 >>> 1. Given the explicit focus on reliability, it's strange that the
 >>> proposal deals with message metadata, which have to do with broker
 >>> or even application behaviour and have absolutely nothing to do
 >>> with reliability. What ensues is a spec where metadata are defined
 >>> as opaque syntactic placeholders with no associated semantics. The
 >>> semantics are meant to be defined on the broker or application
 >>> level. The question is whether it doesn't follow that the syntax
 >>> should be defined on those layers as well.
 >>>
 >>
 >> Both the reliability and message metadata are defined with the
 >> expectation that they are generic for a broad class of MessageBroker
 >> services. The majority of those I'm familiar with could easily make
 >> do with this metadata. The semantics of messages having a text
 >> address, an optional content type, and an optional property list
 >> covers a very broad set of MessageBroker scenarios. On the other
 >> hand, without this additional message metadata, the protocol would
 >> not be usable by any MessageBrokers I'm aware of.
 >
 >I think the argument goes rather like this: If the metadata is to be
 >used by the protocol, the semantics of the usage should be defined. If
 >it's not defined, there's no interoperability. If there's no
 >interoperability, there's no point in having a standard in the first place.
 >
 >>> 2. AFAICS there's nothing in the spec that presumes existence of
 >>> the broker. It can be as well used for direct communication
 >>> between applications. Thus, I would suggest replacing messaging
 >>> broker/messaging client terminology with WebSocket server and
 >>> WebSocket client wording.
 >>>
 >> Yes, while the protocol has been defined for the MessageBroker
 >> usecase, nothing prevents its use in other contexts. On the other
 >> hand, if it were called 'foobar' instead of 'MessageBroker' it would
 >> be hard to explain why it contains the specific elements it does.
 >
 >What I meant was that there are messaging solutions out there with no
 >broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording
 >in the protocol to prevent these solutions to use the protocol.
 >

I was using the term 'MessageBroker' to represent the abstract messaging service the client is using for message transport/distribution. You are right that nothing prevents an endpoint taking on the roles of both client and 'broker'.

Possibly there is a better term for capturing the messaging role of the endpoint a client is connecting to. Please send suggestions ...

 >Btw, I've heard something about Kaazing providing access to Tibco
 >through the web on top of websockets...
 >
 >>> 3. As for reliability itself, it should be clear what kind of
 >>> error conditions is the protocol meant to handle. Possible
 >>> options:
 >>>
 >>> a. Network failure. If so, how does it differ from simply turning
 >>> off TCP keepalives?
 >>>
 >>> b. Client failure and restart?
 >>>
 >>> c. Server failure and restart?
 >>>
 >>
 >> The reliability elements of MBWS are just the protocol elements that
 >> client and MessageBroker use to jointly create and maintain a
 >> connection abstraction. This shared abstraction exists independent of
 >> MBWS. This allows a connection to be 'carried' over an open-ended
 >> sequence of MBWS sessions. Since connections exist independent of the
 >> network, they survive any form of network failure.
 >
 >This is interesting. Can you give an example of such network failure?

Any failure that abnormally terminates a WebSocket session will require resynchronization of the duplex messaging stream for a connection. The session failure could be due to a wide range of issues from hardware problems to TCP timeouts caused by congestion, etc.

In Enterprise messaging, reliable message transport requires what amounts to transport transactions. This adds complexity and overhead. For WebSocket, a stream oriented, message window based resynchronization technique is a better fit. Unlike Enterprise messaging, this distributes the responsibility for reliability equally between client and broker.

 >
 >> The degree to which a connection will or won't survive a
 >> client/MessageBroker failure depends entirely on the ability of the
 >> client/MessageBroker to retain the state needed for it to maintain
 >> the connection across its failure. MBWS does not define how this is
 >> to be done; however, there are many practical ways of doing it. A
 >> client or MessageBroker could fully implement MBWS and only recover
 >> from failed MBWS sessions (i.e. not support connection recovery
 >> across program failures).
 >
 >Ack. The failures of server/client are not addressed in the protocol.
 >You can handle them on top of it though.
 >
 >Martin