Slashdot Mirror
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."
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
of course, look at how fast http superseded gopher.
of slightly more interest to me is the security implications of bxxp. since it's two-way, it could be difficult to filter, and opens up all sorts of interesting possibilities for propagation of virii and spam.
--
Not specifically in regards to this protocol, but I have a small reservation about dropping certain, well used protocols in favor of new ones.
When the Internet was being constructed by a few visionaries like Gore, there was little thought given to security, which is why we are still plagued with insecure protocols like http, (yes, I'm aware of https), telnet, ftp, pop3, etc. However, a blessing is that these protocols were not designed with privacy in mind one way or the other. Specifically, they were not designed to allow the powers that be (government, corporation, etc) to monitor and track activity on them. Let's face it, the internet is still by and large a pretty anonymous place. If I want to be paranoid, I have the ability to pretty much move about undetected.
Enter the 00s (as in year 2000), now the Internet has everyone's attention, and government (and corporations) are kicking themselves that they didn't approach Gore and have him build in monitoring into the protocols since they would LOVE to watch every little thing we do (companies want it because they would monitor customers for marketing reasons, governments want it because they could monitor citizens for 'security' reasons, kids want it because it tastes good, and parents like it because it's good for you).
Given this new era of "how can I get as much info as I possibly can on everyone", I'm always leary of new protocols and such, especially when they are designed to "replace" current ones. Perhaps my fears are completly unfounded in this case, but I think we should all be very watchful about anything 'new' protocol wise.
Finkployd
That's not an SMTP problem. It's a problem with RFC822 (STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES) -based email. SMTP is a *transport* protocol that does the job quite well.
And actually, MIME extensions allow for multipart email, where each part can be encoded differently. I think that works pretty well, too: You can send a bunch of stuff, all of it gets bundled into a single file which again is transferred to the resipient using transport protocols, and the resipient is then free to do whatever he wants with the bundle - usually opening it using a program that knows how to handle such bundles (mail user agents) is a reasonable option. Using software that tries to run every file it gets its hands on is another thing, unrelated to this.
Will be for multi-stream transfering of pornography, right?
BlackNova Traders
I wish all these brilliant minds would work on providing unique and interesting Internet content, which is the part that is sorely needed now.
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 =)
God Fucking Damnit
HTTP is a universally accepted legacy protocol. Unles BXXP is adopted by MS and Netscape for inclusion in their latest browser releases, the average Internet user will probably not have the opportunity to even see it in action. It is nice to think that technically superior methodologies/products will ultimately render older, less efficient, ones obsolete; but look at how long it's taking for HDTV or IPv6 to be adopted! Moving from a legacy communications protocol will probably take at least 5-10 years in a best case scenario.
ByteMyCode.com: A Web 2.0 code sharing community.
It will be interesting to see if all these highly intelligent people can get together and make money.
They already have to some degree. I know Rose worked with Adams in forming PSI, O'reilly, Rose, and Malamud (I think) were involved in the ahead of its time GNN, arguably the world's first Web "destination" (although they didn't manage to make the transition to portal with the arrival of the search engines), and Rose and Malamud have worked togehter on a number of projects from Malamud's Internet TownHall and radio.com (both now defunct) to the Free tpc.int fax bypass network, which failed to generate much interest, although I think it soldiers on in a few locales.
In any case, Rose is one of the best protocol jocks in the world, so in general his suggestions should be taken seriously. One of the most enjoyable classes I ever took was his on Internet mail protocols back at the "old" Interop years ago, back when it was a get-together for the people actually building the Internet rather than a slick merchandise mart with suits hawking the latest lock-in.
"The future's good and the present is nothing to sneeze at." - Roblimo's last
- 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
- 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.
- 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:If you read down through the rest of the article, it mentioned that work was already underway to produce Apache support for BXXP. They estimated that there would be the version of Apache due out this fall would include support for BXXP.
"Sweet creeping zombie Jesus!"
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.
I think something that would be awesome to include in something like this would be a form of redundancy. I'm not sure how it could be done, but one drawback of HTML is that if you can only provide a single location that the browser can grab an image from an image tag for example. If you could list several locations in the code for the same image and have it be transparent to the browser, that would be helpful for example if a web server went down that was holding your images. Or if you could do the same with links, where there's only one place for the viewer to click, but it will try all of them in the list until the browser finds one that works. This could even be extended to randomly choose one of the servers in the list. This could be a form of HA for people that can't afford the Real Thing(tm), and it goes without saying that it could help at least meet some of the shortcomings of today's web.
:P
Another thought that I had was a [somewhat primative] form of load balancing for servers that actually took place on the client side (which would sort of crudly happen with the randomized link idea above). Before downloading everything off a site (images, video, etc.) the browser could go through some sort of ping function to see which server was closest to it in terms of latency or availability, or better yet it could be coded into the server to report it's bandwidth/CPU load or some sort of combination of relevant data to the browser and let the browser decide which server would be best to obtain the data from. This routine would be outlined at the beginning of the code for the web page. This could also be extended a great deal to even include things like distinguish between data types to help choose servers accordingly, etc.
If you think about it, HTML/web servers could be much more intelligent than they are now, and the best time to add intelligence would be when adopting a new format like this. While we're at it, we should also do a bit more to protect privacy. Intelligence combined with privacy... could it be possible?
Something similar to this in terms of redundancy also needs to happen with DNS and is long overdue. Just had to add that.
My two cents...
--SONET
"Open bombay doors!"
Any fool can criticize, condemn and complain and most fools do. --Benjamin Franklin
While "X" is still technically one syllable, it doesn't trip off the tounge quite like "T". There are two tounge motions in that one syllable, "Eks". We need a more streamlined protocol name. Make it something catchy like Extensible Exchange Enabler and call it Tripoli. Easy to type, too.
Forget the network performance tests! Any new protocol should have to undergo verbal performance tests.
Also, if I see one more thing with an unnecessary secondcap X in it, I'm going to hurl.
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.
If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime
Here is the IETF working draft of the protocol. Lots of good info on the architecture of the protocol.
-NOC Monkey (OOK!) Experience is what allows you to recognize a mistake the second time you make it.
And BXXP won't get rid of all the different protocols; what it might do is provide a common framing mechanism for protocols. Which means you have to do just as much work in protocol design determining semantics of what each extension and flag and whatnot else carried within the framework means. (And HTTP has some very well-developed and real-world-motivated concepts and semantics, f.e. in the caching and proxying and transactional areas; don't expect those to disappear any time soon.) It could, I suppose, makes it easier to build parsers, to which I say two things:
...and all are incompatible with things that already exist, I suspect that some intent other than improvement of the protocol is present. For example, XML demands to use Unicode (to be exact, standard was designed to make it really hard to do anything else unless everything is in ASCII). HTTP 1.1 is a one huge spec with various wild demands to applications made across all levels of content, presentation and transmission means, that can't be implemented separately of each other while remaining compliant to a spec. Java is both a language and a bunch of libraries that can't be ported or reimplemented in anything but java itself. And now more or less reasonable proposal of having one more level of multiplexing (compared to multiple TCP connections -- one however may argue that it would be better to attack the problem at its root and make a congestion control mechanism that can work across connections) is tied with use of XML instead of well-known, more efficient and more flexible MIME.
Good ideas that can be implemented separately are used to push dubious-quality "standards" that provide no benefits but pushing useless, semi-proprietary or simply harmful "inventions" by combining them in the same spec.
Contrary to the popular belief, there indeed is no God.
From what I can decipher, this seems to be a more extensible protocol, which would allow easy creation of network-aware applications. My question is, since there is an added layer of abstraction, wouldn't there be an overall performance hit?
Besides, wouldn't multiple "layers" of data on the same connection open tons of potential security risks?
Or am I off my rocker on both counts?
--
We may not imagine how our lives could be more frustrating and complex—but Congress can. – Cullen Hightower
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.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
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.
The problems with getting anyone to adopt a new protocol can be summarised as:
To be adopted requires more than functionality. It requires a market. No users, no use.
Multicasting suffers a lot from this (partly because ISPs are die-hard Scruges (minus any ghosts to tell them to behave), but mostly the lack of users, plus the high cost of ISPs switching will forever prevent this genuinely useful protocol ever being used by Joe Q Public. (Unless he really IS a Q, in which case, he won't need an ISP anyway.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)