Re: Protocol Bindings

> Actually, I am not a believer in layered multiplexing as it causes a
> number of problems, see for example [1]. In addition, as it from an
> application point of view, doesn't address any head-of-line blocking
> problems, increases the risk of dead-locks, and because the interleaved
> channels are interconnected, one cannot abort channels in an independent
> manner, I can't see the benefit (not that I haven't tried - some may
> remember WebMux [2]).

mileage varies. as for the problems:

    head-of-line blocking goes away when you do segmentation and
allocations, the cost is that you sacrifice the ability to operate at TCP's
theoretical speeds.

    deadlocks, as a potential problem, exist independently -- either due to
poor protocol design or poor protocol implementation.

    channel aborts can be handled with prioritization of a control channel.

none of this is rocket-science, it just requires careful engineering and
reasonable implementation. as for the benefits:

    when you are able to amortize the cost of connection establishment,
security neogitation, and state restoration for transactions involving more
than one exchange, the benefits become noticable.

    when you are able to operate asynchronously in a loosely-coupled system,
the benefits become noticable.

is the benefit worth the extra cost of complexity: that depends on whether
the layer is available as a well-implemented library, or whether each
programmer has to figure this stuff out for themselves.


> If you want to have that flexibility then why not simply do SOAP-RP/DIME
> over multiple TCP streams?

because, in today's operational environments, if you originate two tcp
connections to the same ip address at the same time, you have no guarantee
that they terminate at the same system. 10 years ago, this wasn't an
issue...

regardless, when you do multiple tcp connections, then there's a whole other
set of problems that pop up with firewalls, viz., ftp-data for the simple
case...

/mtr

ps: when you say

> I can't see the benefit (not that I haven't tried - some may
> remember WebMux [2]).

presumably, at some point you, or someone else, did see some benefits,
otherwise there wouldn't have been work on webmux. as to whether webmux
failed because of the problems you cite, or because adding anything
incompatible to http 1.0 was a non-starter, is another issue...

Received on Sunday, 8 July 2001 07:16:27 UTC