W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2000

Re: XML protocol comparisons

From: Marshall Rose <mrose+mtr.netnews@dbc.mtview.ca.us>
Date: Wed, 5 Apr 2000 21:11:28 -0700
Message-ID: <00fb01bf9f7e$2fdd6f40$6d61fea9@dbc.mtview.ca.us>
To: <michaelm@netsol.com>, "Justin Chapweske" <justin@cyrus.net>
Cc: "Henrik Frystyk Nielsen" <frystyk@microsoft.com>, <xml-dist-app@w3.org>
> On Thu, Mar 30, 2000 at 02:23:50PM -0600, Justin Chapweske wrote:
> > I know that someone mentioned BXXP on here before, and I just have to
> > ask what if any value does it provide over the webmux protocol that was
> > specified for HTTP-NG?  There are so many juicy gems to be gathered from
> > HTTP-NG, so even though it may not have happened as a whole, I still
> > think the individual components are valid.
>
> One major one is that BXXP doesn't say anything about what it transports
> or what its interaction model is (other than session oriented). One of
> BXXP's goals was to allow for a protocol where the actual elements
> were unlimited. The outcome is that BXXP can frame and multiplex
> anything that can be encoded in a MIME body. The channel maintenance
> stuff is in XML but that doesn't mean the actual protocol elements
> have to be...

michael - hi.

the smux/webmux protocol does multiplexing of octet streams over a single
tcp using a credit-based approach.

the framing mechanism in bxxp does multiplexing of request/response message
streams over a single tcp using a window-based approach.

a careful diff of these two sentences should illuminate the differences:

1. there is more to bxxp than framing, e.g., user authentication, transport
security, and channel management (though you could layer that extra stuff on
top of smux if you wanted to define it all)

2. smux is more general than bxxp's framing mechanism in that bxxp enforces
a loosely-coupled messaging semantics (i.e., boundaries, request/response
relationships). again, you could define LCMS on top of smux if you wanted.

3. a credit-based approach is adequate for flow control if you already have
tcp in place; the reason we went with a windowing-based approach (which
sends an additional parameter) is that it allows for more robust detection
of implementation errors. (a secondary reason is that by using the identical
mechanism that tcp uses, we don't have to have any arguments with anyone as
to whether or not it "works")


> BTW, I talked with Marshall after the meeting about a UDP version and
> he thought it was doable, especially if you require the frame (segment)
> size to be under the 512 byte limit....

there was some talk about this last week in adelaide. the spooky part is
that it might actually work...

/mtr
Received on Thursday, 6 April 2000 00:12:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT