Will BXXP Replace HTTP?

Stilgar writes: "Seems like one of the Internet architects, Marshall Rose, is at it again. This time he invented a Blocks Extensible Exchange Protocol (BXXP) which seems a *much* nicer alternative to the aging HTTP (if the IETF will give it a chance). Check out the story at NetworkWorldFusion news." From the article: "One special feature of a BXXP connection is it can carry multiple simultaneous exchanges of data - called channels - between users. For example, users can chat and transfer files at the same time from one application that employs a network connection. BXXP uses XML to frame the information it carries, but the information can be in any form including images, data or text."

Comments

BXXP is not a protocol

[Fzz]

I was at the IETF meeting in March where Marshall presented BXXP, and I think there's some misunderstanding about what BXXP really is. It isn't a complete protocol in the same whay that complete HTTP is a protocol. It's more of a protocol framework, which you layer new protocols on top of.

HTTP was designed as a single-use protocol. Because it's understood by firewalls, etc, it gets used for just about everything, even if it's not really appropriate.

BXXP aims to provide a well thought out common building block for a whole class of new network protocols. If HTTP was being designed after BXXP, then the obvious thing would have been to layer HTTP on top of BXXP.

So, really BXXP isn't intended to replace anything. It's intended to make it easier to deploy new protocols in the future.

-Fzz

BEEP?

[cxreg]

Don't you think that BEEP is more pronouncable than BXXP? Plus, it would be fun to tell people that I write in BEEP. We could even use the censopship icon for related Slashdot stories =)

Re:HTTP

[_xeno_]

Unless BXXP is adopted by [Microsoft's] and Netscape['s latest browsers]...

And by Apache, and in Java... Don't forget the server end. The radio in my car can pick up many different frequencies, but unless someone is actually broadcasting on a given frequency, I'll be getting static.

Apache 2.0 including BXXP support would go a long way towards it being used, as over half the websites in the world are run on Apache. Support in the Java java.net package for BXXP URL connections would also help enabled BXXP in a wide variety of applications.

Support for new technologies client-side is nice - but unless there's also support server-side, the technology can't be used.

HDTV is taking a long time to be adopted simply because of the expense to purchase a set - at $1000 a set, it's not surprising people aren't rushing to get one. Yeah, it'll take time - but all it takes is a few sites to start using BXXP, a few services, and a few web browsers to support that, and eventually, it can come into it's own right as a internet protocol. But it may be coming sooner than you think.

Re:Why multiplex over one TCP connection?

[artdodge]

Why multiple connections are a bad idea:

1. Because multiple TCP connections do not share congestion information, it is possible for a greedy user to get more than his "fair share" of a pipe by using many parallel connections
2. Each TCP socket takes up system (kernel) resources on the server. Forcing the server to maintain a larger number of connections will cause its overall performance to take a hit.
3. It introduces throttling/aggregation difficulties for proxies (see RFC2616's requirements for maximum upstream/inbound connections from a proxy; a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself, and will waste the proxy's resources [see 2], ergo degrade its performance).

Why MUX (HTTP-NG's name for this idea) is a bad idea:

1. (If not done intelligently) it introduces artificial synchronization between responses, i.e., your quick-to-serve GIF could get stuck "behind" a slow-to-serve Perl-generated HTML page in the MUX schedule
2. As a general case of [1], creating the MUX schedule and framing the data is hard, and difficult to parameterize (Where do progressive GIFs chunks go in the schedule? What if the browser doesn't support progressive rendering of HTML? What size chunks should be used in the schedule - a low bandwidth client might prefer smaller chunks for more "even" fill-in of a document, while a high bandwidth client would prefer bigger chunks for greater efficiency)
3. DEMUXing is more work for the client at the application-protocol level.

Aging compared to how it's being used

[Cardinal]

The difference between FTP/SMTP and HTTP is that FTP/SMTP are still to this day used for exactly what they were speced out to be used for. File transfers, and mail handling. So even if they are older than HTTP, they haven't aged in the sense that very little is being asked of them beyond what they provide.

HTTP, on the other hand, has been stretched far beyond what it was intended for by today's web. It's stateless and simplistic, yet we that write web applications need it to be more than that. This gives it the sense of being an "aging" protocol. Session management of any form with HTTP is a dirty hack at best, and web applications needs a better answer if they are to expand beyond what it is now. If BXXP can speak to those shortcomings of HTTP, then all the better.

*AHEM* - BXXP is not intended to replace HTTP

[orpheus]

Despite what the author of the linked article suggests, even the experts he interviews agree that BXXP is intended to be a more flexible and capable alternative to HTTP, but its major use will be as an alternative to completely custom (open or proprietary) protocols for new applications, not for webserving ordinary HTML.

"Think of BXXP as HTTP on steroids," says Kris
Magnusson, director of developer relations at
Invisible Worlds. "People are trying to jam all
kinds of things into HTTP, and it has become over-
extended. BXXP won't replace HTTP for everything,
but it can be used when new applications protocols
are developed."

As such, it does not conflict with, or supplant HTTP-NG, or many other standards being hammered out by the IETF. It's just another tool developers and info provider may choose, depending on their needs.

The IETF draft for BXXP

[NOC_Monkey]

Here is the IETF working draft of the protocol. Lots of good info on the architecture of the protocol.

Aging??

[Mark F. Komarinski]

HTTP is the youngest of the Internet Building Block protocols. Heck, all the other protocols are at least twice the age of HTTP.

Inadequade, inefficient, and slow are adjectives I'd use with HTTP. Aging I wouldn't use. That implies that FTP and SMTP are both old and thus should be replaced. The age of a protocol doesn't matter. What matters is if it does the job.

reliable datagrams

[jetson123]

I think it would be preferable to have a reliable datagram service in the kernel, as opposed to yet another messaging library built on top of TCP.

The need for reliable datagrams ("block exchanges") comes up frequently for file servers and similar systems (like the web), as well as distributed computing, and not having such a protocol as part of TCP/IP was a major omissions. For example, NFS simply assumes that UDP is reliable over a LAN, Plan 9 built a reliable datagram server into the kernel, and HTTP/1.0 just treated TCP as a (slow) reliable datagram service (send request/receive response).

An advantage of reliable datagrams is that it avoids most of the overhead of negotiating and establishing a TCP connection, so it can be almost as fast as UDP. Furthermore, reliable datagrams require fewer kernel resources to be maintained, and the send_to/receive paradigm is a better fit to many applications.

BXXP looks like it requires quite a bit of stuff: a TCP/IP implementation, the protocol implementation, and an XML parser. That's going to eat up a lot of space on small devices, and it's going to be unpleasant to implement and debug. The connections on which BXXP runs will also eat up kernel resources (file descriptors, etc.), both a problem on small devices and on very large servers, and it requires even more code and modeling to figure out when to bring up and tear down connections ("is the user going to request another page from that site?").

Furthermore, routers and other devices would have a much harder time understanding what is happening inside BXXP; that's important for things like multicasting and predicting bandwidth utilization. In comparison, reliable datagrams are a simple addition to a TCP/IP stack and require no protocols or parsing. And routers and other infrastructure can deal with them much more intelligently.

Plan 9 has a reliable datagram service called IL, although it is only optimized for LANs. People have also been working on reliable datagram services as part of IPv6, and for Linux.