Re: [hybi] (no subject)

[Martin Sustrik <[e-mail]>]

Hi Mark,

>  >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.

The great thing about JMS was that it actually defined the canonical 
semantics of a messaging system. (Kudos, btw!)

If it was just function signatures without an explanation what the 
individual calls are meant to do, it won't be pretty much useless.

I think the same principle applies to wire protocols: Don't add anything 
to the protocol unless you are explicit about how it should be used.

>  >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 ...

I would apply Occam's razor and go for "WebSocket server" and "WebSocket 
client".

In traditional broker-based setting "WebSocket server" pretty 
straightforwardly translates to "messaging broker" and "WebSocket 
client" to "messaging client".

Brokerless solutions are free to interpret the roles as they see fit.

Btw, getting rid of broker/client terminology allow for using the 
protocol for broker-to-broker federation as well.

>  >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.

What's interesting here is that that's exactly what TCP is supposed to do.

Obviously, there are issues with TCP reliability algorithm. It would be 
nice to identify those deficiencies and enumerate them in the 
introduction. (Are they deficiencies of TCP as such? Or maybe just 
problems with TCP implementations? 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.

Definitely. Dealing with transactions is a mess.

Martin