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."
it may be that there are great advantages, but completely changing a protocol that has been the main-stay for so long is difficult, if not impossible!
kick some CAD
If BXXP is significantly more complicated than HTTP, I don't see it replacing HTTP. HTTP (and HTML) became widely popular because they are very simple to write code for. If I have a quick program to throw together that makes a socket connection to a remote server to retrieve data from a custom CGI query, I'm going to use HTTP because it's a simple process of sending a URL as a request, then reading until EOF the results of that reqeust. If BXXP requires abstractions such as XML and the overhead of writing multithreaded code just to pull down a single document, then I'll stick to HTTP, thank you.
BXXP may find a niche, but I doubt it will replace HTTP.
Please consider making an automatic monthly recurring donation to the EFF
Yes, it's funny, I'll concede that. But when you think about it, it's the ideal acronym.
:) )
Blocks
Extensible
Exchange
Protocol.
That looks like BEEP to me. It's easier to pronounce than "ay she cheat chee peep" or however you end up mispronouncing "HTTP".
And as for "beex"... "bee ix bix"... "beep ex pexip"... ah, screw it, I'm calling it beep anyways! You can't make me call it "bxxp"!
(Hell, you can't even help me call it that... I'd rather dictate a thesis on the merits of Peter Piper picking pickled peppers.
No boom today. Boom tomorrow. Always boom tomorrow. BOOM!
Just to shout out for a bit, in an age where browser source is open (Mozilla) as well as the servers (Apache), if there is a better protocol, implement it! Hell most of what is trendy in HTML is there only because Netscape/Micro$~1 thought they'd throw it in. If you document it, and release working models of the software into the wild, it will get used.
The same thing with DNS entries. The only thing stopping people up to now has been the fact that noone wants to foot the bill for alternative root servers. It makes you wonder if something like the distributed gnutella mentality would work for DNS look ups.
I guess I'm saying ditch this 'they' shit. Do it, and if it's a good idea, or if a ton of people start to use it, you can bet someones going to try and capitalize on it.
If you build it, they will come.
Multicasting isn't easy. Multicasting is not something that just needs to be implemented, it is still a subject of research, trying to find efficient ways to handle millions of endpoints on the Internet. The current experimental implementation (MBone) implements some experimental multicasting algorithms - some of them involve flooding to find out who wants something.
The question is who should manage receiver lists - the server, ISP's routers or multiple levels of routers - and how to do that without creating megabyte sized lists that can't be handled by routers without slowing them down immensely. Another question is how should the start/stop of a stream receive be handled - regularily initiated by server/router or by the client.
It's not for ecoonomic reasons that multicast hasn't caught on (hell, there'd be lots of economic reasons to push it on everyone!), it's that there really isn't any widely usable multicast mechanism ready yet.
This is functional programming in my book: You describe what to do, not how to do it. Namely a specification.
OOP and functional programming is not contradictory.
Of course I wouldn't call this programming at all, or a protocol. I would call BXXP a meta-protocol.
- Steeltoe
http://www.debunkingskeptics.com/
There are tons of tools out there that can speak HTTP, infact, HTTP is so simple that you could probably do it by hand (in fact, I know I've been both client and server)
And as far as 'multiple channels' that can be done with multiple HTTP connections over TCP. BXXP may be a little better, but it's got to be a lot better for people to want to use it over HTTP.
ReadThe ReflectionEngine, a cyberpunk style n
Well, the hard part in all this is the legal stuff.
Ahem. Communication protocols do not solve legal problems.
instead of needing to sniff on a router, there was a "secret" stream of data that went to some big government of corporate harddrive?
With government this is not a problem. Evidence obtained without a warrant it inadmissible and besides this amounts to illegal wiretapping and will cause huge outcry when (note: not if, when) detected.
With corporation this is somewhat of a problem, yet I don't see any ways in which new protocols would make logging of my actions easier. Not to mention that forking a stream of data is rather trivial and does not need any special protocols.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
The way I'm reading this, BXXP is a framework, or a layer, on top of which it's very easy to implement other protocols. Sounds great for ease-of-use and prototyping, but like most things that make work easier, it adds overhead. If you've got things prewritten, it's not possible to completely optimize it.
Actually, I don't think I'm confused. You've hit the nail on the head: why create a protocol in the *application* layer, when there are protocols that solve these problems in lower-level layers?
I'm sure there are good reasons to re-implement these in the application layer. But what are they?
BXXP (or BEEP) is a good start, but not quite what I want or need as a e-commerce developer.
Currently if I want to design a "fully" interactive site that behaves the same way an application would I'd have to write some kind of java gui, for portablility reasons, that communicates back and forth to some central server running a specialized program that listens on some unused port and processes my cryptic and hastily thrown together messages. However, this is a lot of work, and with my message structure changing every few days its extremely difficult to manage, since you have to change the server and client code.
What I'd like to see is a new protocol with its own server, an application server vs. the current web server. I envision something like an asynchronous connection where both ends pass standard messages back and forth in real time, something similar to the messages passed back and forth between an OS and an application. It would also have to have what everybody is screaming for, one persistant connection, encryption, user validation, and a whole slew of other things I can't think of now.
The main problem is agreeing on a standard messaging system that isn't OS specific, allows users to format data however they wish, and still provides a means for expansion without dozens of revisions before a stable and workable model is created.
Along with this there would need to be an update to web programming languages, yet another java package, or maybe even a whole new net language. This would turn the current web browser into an application browser, where one program could act as anything you wanted it to be. I suspect this is what MS is doing or intends to do, however I doubt they'll open the specifics to everyone, at least not without signing a disclosure agreement.
Well with all that out of the way all we need to do is come up with some acronym. I recomend nssmp (not so simple messaging protocol), or how about wrcwicp (who really cares what it's called protocol)?
- For starters, it's based on TCP. TCP is reliable, delivering an inorder stream of data. In addition it will ALWAYS retransmit lost packets, and has an exponential backoff/slow start that tries to avoid congestion. These are wholy inappropriate for gaming applications, where the state of the game is constantly and rapidly changing, and if a packet is lost, fuck it, it won't matter in 1.5 seconds anyways. The exponential backoff could really screw over a game with lag. In addition streaming is not necessary, data should not always be dependant on earlier data. If reliability or order is needed, it can be solved with a 1-byte sequence number, TCP is overkill.
- XML is overkill. Most game packets are heavily compressed, and very minute. Usually, packets are stuck together and sent as ~400-1400 byte UDP packets. Formating game state data as an XML stream is not just inefficient, it's horribly stupid.
- If a game needed to mutliplex channels, it could do it internally, or open multiple UDP ports.
Sadly, as far as games go, it will probably be just another way to get around corporate firewalls---
I am the dot in slashdot.org
Multiple TCP connections don't have to be bad. Look at http://wind.lcs.mit.edu/projects/cm/. A nifty research project that mitigates the negative effects of multiple tcp connections.
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
In this case, no, not even close.
The W3 has shelved HTTP-NG, and is instead focusing on SOAP/XML transport standards. They would likely ignore BXXP without a second thought.
On their own, Invisible Worlds has zilch chance of making this a de facto standard.
You and others keep making these "example" XML documents, but who is to say that a BXXP document will look anything like them? Why couldn't it be:
<bxxp>
Content-Type: text/html
Content-Length: whatever
Other-Headers: Other-Info
<HTML>
my HTML document here
</HTML>
</bxxp>
There's no reason you need any more of a wrapper than one tag. All these assumptions are totally baseless. It _could_ be bloated, or it _could_ take no more than 13 extra bytes per request.
---
Tim Wilde
Gimme 42 daemons!
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
Doesn't greedy user mean sophisticated user in this case? There's not much trouble there- that's the slashdot demographic(c). Anyway and most people are aolusers or otherwise 'newbies for life'. They are not going to utilize this 'weakness' unless there are apps written to do it for them.
Maybe you mean this would happen by opening too many ports on the remote server kinda (only sorta though) like a ddos attack? are you suggesting the latest in traffic managing protocols won't take ddos-like situations into account?
:)Fudboy
:)Fudboy
I guess I'm only a Fudboy, looking for that real Transmeta
However, the development of useful content on the server side requires each we publisher to incur an additional expense. As such, there must already be a critical mass of supported clients available for it to be cost effective for them to rewrite existing applications.
Would it be terribly difficult to write something that translates HTML into BXXP (or vice versa) for those not wishing to incur the overhead of doing something twice?
Be nice to your friends. If it weren't for them, you'd be a complete stranger.
I constantly rue the fact that the "www.blahblah.com" convention won out over "web.blahblah.com". The amount of time I waste saying and listening to "Double-Yew Double-Yew Double-Yew" instead of the one syllable "Web" is enough to take an extra week of vacation every year. (thank the gods radio announcers have at least stopped saying "forward slash forward slash")
You know, WWW is the only acronym that has more syllables than the whole name (i.e., world wide web).
--
This space left intentionally blank.
Despite the moaning and groaning on the forum here about XML, I happen to like it. Its all well and good for keeping information in human readable form, and makes writing extractors fairly painless.
The main strength that it has is it could provide a mechanism to exchange freeform XML metainformation about the channels to the applications without requiring the applications to reinvent the wheel each time. I like this aspect of the protocol, but I think it could be done with less baggage, by leveraging the existing lower level protocols more.
The main barrier it has to adoption is that it is yet another protocol that will have to be micromanaged by firewalling software. I do like the fact that this could probably be run raw over any serial link, but again, you could just use PPP.
Sanity is a sandbox. I prefer the swings.
This is a good troll - the best kind, actually. This is obviously not Sig 11, as anyone who checks the user profile can tell. However, the language of the troll is particularly convincing. Best of all, he/she/it makes a lot of good points. The gist of their argument is that BXXP is unnecessary - that TCP/HTTP already does everything that is needed. TCP does support more than 700kbps, HTTP 1.1 does permit persistence, etc. Very well done, and it's already trolled one or two people.
Moderate them down Troll. Moderate them up Funny. Just PLEASE don't moderate them Interesting, Informative, Insightful, or Flamebait, because they're not.
Actually, Dan Bernstein, the author of qmail, is already ready with QMTP (Quick Mail Transfer Protocol), a replacement for SMTP.
I understand the limitations of HTTP (too many connections that are expensive to set up, no multiplexing of channels, not robust or consisent when handling errors, etc.) but why a new protocol--why not just use basic TCP or UDP sockets over IP? After all IP handles packet sizes, TCP manages packet retransmissions, etc. For protocols that don't need TCP services there's UDP.
After all, HTTP has only become overloaded because that's the one protocol that was pretty much guaranteed to make it through everyone's firewall, whether the firewall just blocked ports or actually sniffed packets. It would make sense to have a new meta-protocol, on a standard port or set of ports, so that true Net applications can communicate even through firewalls, but...does it justify a whole new protocol?
I dunno. It seems to me that current firewall designs--valuable though they are--are not a reason to duplicate existing protocols. With all due respect to BXXP's creator, it smacks to me of a case of NIH--building it just because he wanted to write a new protocol.
??
Firewalls are there for a reason - if you tunnel other protocols over HTTP, you are bypassing the firewall and had better have a very good reason for doing so. Lots of vendors do this, including Microsoft with DCOM and many CORBA vendors as well, but that's not much of an excuse.
Firewall-hostile is a better term for protocols that carry many different types of data.
As a QoS weenie (see http://www.qosforum.com/) I also don't like the way that HTTP can carry many different types of data requiring different QoS (performance) levels, e.g.:
- DCOM over HTTP: needs fairly low latency
- CGI transactions: ditto
- RealAudio over HTTP: needs low loss, consistent bandwidth
- static pages and images: no particular QoS needed
The only way to handle this is to classify every type of HTTP interaction separately, using URLs to map packets into Gold, Silver, and Bronze QoS levels. This is feasible but fragile - as soon as the web-based app or website is updated, you may have to re-write these rules.
Even worse, HTTP/1.1 puts all interactions with a given host into a single TCP session (a good idea in many ways), which makes it a waste of time to prioritise some packets ahead of others - the receiving TCP implementation simply waits until the out of order packets arrive, sending a duplicate ACK in the meantime. Severe packet re-ordering may even lead to slow start in the sending TCP (three duplicate ACKs means slow start from a single packet window size).
Similar issues apply to security - you might want to encrypt only the transaction data and not bother encrypting images, for example, or route some data via a more secure network. SSL does solve some of these problems but requires application support.
Oh well, enough ranting - HTTP is a great protocol in many ways, but there are costs as well as benefits to abusing it to do things it was never meant to do...
Do you have references on the reliable unicast protocols being worked on for IPv6 and Linux?
There are many reliable multicast protocols around, some of which at least should work for reliable unicast as well, e.g. RAMP (
http://www.metavr.com/rampDIS.html). See http://www.faqs.org/rfcs/rfc2357.html for criteria for reliable multicast protocols, has some good references.
There is also T/TCP, a variant of TCP which is intended for request/reply transactions - it lets you send data with the initial SYN request and get data back with the ACK, so it's not much less efficient than UDP-based protocols. It would be ideal for HTTP/1.0 but has not really been deployed much.
RADIUS uses its own reliable unicast approach over UDP, and is widely deployed, but it's not a separate re-usable protocol. See www.faqs.org for details.
Some problems with reliable unicast are:
- congestion control - there's no congestion window so it's very easy to overload router buffers and/or receiving host buffers, leading to excessive packet loss for the sender and for other network users
- spoofing - it's even easier to spoof these protocols than with TCP (I think this is why T/TCP never took off)
As for BXXP - I agree about difficulty of understanding what's going on. QoS-aware networks and firewalls all prefer one application mapping to one (static) port.
"...provides reusable code for basic data exchange between systems"
Does this smell like Java to people? Obviously, the comparisons have to be limited considering the disparate usages of these two systems. It's definitely an exciting technology, and provided that backwards compatiability with the HTTP protocol is maintained (this should be trivial considering the extensibility of this spec)this could be a god-send (Just make sure it MAINTAINS STATE)
One thing that I'm worried about is the extensible nature of the spec. This would seem to present the same possibilities as the Sun/MS controversy over the proprietary MS instructions contained in their VM - what's to say that can't be done in a browser?
The article doesn't concentrate the exact nature of the extensibility of the BXXP speca and that worries me somewhat. Obviously, since it uses XML, objects can have context, but still I'm worried about 3rd parties (i.e. M$) creating proprietary "extensible" features.
Is there any more sources of information (other than the links provided) on this spec?
One big reason for multicast not catching on is the ability for a single multicast sender to cause congestion at many different points of a network, along with the problems of multicast network management. Until multicast becomes manageable its adoption will be quite slow. A useful paper on this is ata naging.htm
b .htm
e -sgm-00.txt
http://www.winsock2.com/multicast/whitepapers/m
There's some interesting work on fixing this, though - I forget the details but a recent IEEE Networking magazine had a special issue on multicast including info on why it's not been deployed yet.
Also, for small groups, there is a new protocol called SGM that runs over unicast UDP and unicast routing - the idea is that if you want to multicast to a group of 5-10 or so people, and there's a large number of such groups, you're better off forgetting about IGMP and multicast routing, and just including the list of recipients in the packet. Very neat, though it still requires router support. Some URLs on this:
http://www.computer.org/internet/v4n3/w3onwire-
http://www.ietf.org/internet-drafts/draft-boivi
http://icairsvr.nwu.icair.org/sgm/
Here is your Daddy-o.
Hamish
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
Except that the difference between rolling out HDTV and a replacement for http is where the changes take place. With HDTV you have to upgrade the equipment at the broadcast and receiver end. You also have to deal with limited bandwidth for broadcasting that makes it difficult to serve both technologies at the same time. With a protocol change, you can transition more easily by including both standards in your browser and on the websites. How many sites already keep multiple formats on hand? Do you want frames or no frames? Do you want shockwave or no shockwave? Would you like to view the video in RealPlayer or Quicktime? I can update my browser for free. How much does that new HDTV box cost?
carlos
--
As a matter of fact, I am a lawyer. But I play an actor on TV.
and yeah, I realize that the goal of this is for protocol development, but I am curious on how the apache stuff they mentioned would work. Thanks!
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.
Can we learn to spell 'wheel' correctly please!! Or is this an Americanism that I'm not aware of as a 'dumb limey'??
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.
--
The idea of new protocols being approved by the IETF got me thinking about what other technologies they might consider. It occurred to me that Napster and Gnutella potentially open up considerable possibilities for new application architectures as well, since they essentially provide a nice distributed storage & lookup mechanism that could be used for a variety of purposes besides pirating music.
Has the IETF weighed in on the Napster/Gnutella debate? If so, what do they have to say about the technical merits of those protocols?
From what I understood, HDTV is a failure because it doesn't solve problems.
When you ask what's wrong with TV now, you find "content", "it's boring",...
The problems are with the content (that's why you are reading Slashdot instead of watching TV), not the image quality.
1050 o 1250 horizontal lines are not enough to spend the money at both the emitting and the receiving ends.
Of course, prices would go down after massive engagement, but there is not enough of inital adoption.
Digital TV on the other side promises more channels on the same medium. The content will as bad or worse, but there will be more of it. So Digital TV has more of a chance to replace PAL, SECAM & NTSC
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
If he calls it a framework why isn't the acronym BXXF (or better still BEEF)?
Special Relativity: The person in the other queue thinks yours is moving faster.
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
For some years now, the W3C has been playing with the idea of URNs or URIs (I don't remember). These are an evolution of URL that don't specify machine location. But I have never found if there are suitable implementations.
Hacking HTML for multiple destinations is at most a kludge.
A promising thing is at Freenet. You specify what document you want and say nothing about it's location.
About load balancing, I remember that the WBI web proxy (somewhere at IBM's AlphaWorks) had an option to do a ping for every link in the page and insert an icon marking slow from fast ones. I found it interestin until I realized that final layout of the page had to wait for the slowest ping.
__
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu
You probably have that much unused blank space in the last packet of any file you send. Non-issue.
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
NFS is stateless and works by sending the same datagram repeatedly until it receives an aknowledgement. That is, IMHO, a terrific use of UDP and shows the lack of need for a so called reliable datagram protocol. For a datagram protocol to be reliable it will have to send (and cache) some sort of packet number or something and then send a response back. You could already do the same thing by doing your own packet number chaching and acknowledgement with UDP.
WTF? IMHO, and BTW, IANAL, but IIRC, BXXP is A-OK, i.e., BXXP != HTTP/FTP (so STFU about that), but AFAIK, BXXP could be used for chat via TCP/IP (like IRC, et al). OTOH, BXXP == XML, and with XML, YMMV.
/.
Most of that was nonsense, but hey, it shows where things are heading. But NEways, I'm going AFK, BBIAM.
AC on
EOF
There's an RFC covering an extension to TCP for LFPs (long, fat pipes). It allows larger packets to be sent by increasing the space used to hold packet size info (I think it uses some unused field). I don't know which RFC exactly, but it should be easy to look up.
The reason this is an issue is because a link that can transfer a huge amount of data but with high latency will end up being limited by having to wait for ACKs before advancing the window. Of course you have more ACKs to wait for if you have more, smaller packets. The easy fix is to increase the packet size. You have to counter this however with the reliability of the link, or you end up constantly resending a huge amount of data.
Scuttlemonkey is a troll
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.
There is a lesser-known but even simpler extensible protocol designed to do the same thing as BXXP. The draft was published in February 1999 and expired unchanged in August 1999. Have a look at the draft defining Extensible Protocol (XP).
...and I'wondering if the titles ("Will BXXP replace HTTP?") are designed to make it easy to discern who read the article and who didn't. As I understand it, BXXP mainly functions as a platform on which to build other protocols, with most of the "dirty work" abstracted away for you, not just some replacement for an existing protocol. Sounds pretty nifty to me.
Yo dawg, I heard you like the Ackermann function, so OH GOD OH GOD OH GOD
"http://www" is now a household word. Imagine moving to "bxxp://www"...all those advertising dollars lost... ;)
Will be for multi-stream transfering of pornography, right?
BlackNova Traders
This addresses the biggest limitation in HTTP, which is that HTTP is essentially a page-based protocol. It's like the difference between 3270 terminals, and raw-mode ASCII. The 3270 was essentially a glass Hollerith card: fill out a form, send it in, get a whole screen back. This approach will make it possible to do things like interactive chat without resorting to abortions like Java. -jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
Not to cast dispersions upon fellow slashdot readers, but it seems that many of us don't read beyond the headline. WTF!? There's almost a hundred posts to this story, and like 5 that actually understand why this will be useful. Slow down, and try to understand what's going on.
As I see it, replacing HTTP is probably not going to be the first application of the BXXP protocol. In order to see the beauty of BXXP, you must consider the plethora of existing protocols (SMTP, HTTP, FTP, AOL-IM, ICQ...) none of which would be seriously hurt by a minor increase in overhead. Using a common language means that you don't have to write an RFC822 (or other RFC) parser for every application that wants to send mail, or request a file, or send an informational message/status update. You can parse the XML, and get the relevant info with much less effort using common code. You could share common headers between email and instant messanger clients. They're similar enough to speak IM to IM, or IM to mail server... Share libraries == less programming. Shared libraries == fewer bugs (theoretically).
I speak from experience. I'm working on a client/server framework for a project that I've been doing for too long, and I've reached the end of my original communication protocol's useful life. I've switched over to an XML based format, and I'm happy with it. If I'd had BXXP to start out, I could have avoided writing two different communications protocols, and spent that time working on better things.
Since they announced they own the Internet/Web last week, I wonder if they will approve this new protocol? How about BXXP#?
Anyone who's actually had to deal with ASN.1 or SNMP will think twice about instantly embracing another Rose protocol. (Last I heard, though, he had admitted that using ASN.1 was probably a bad idea.)
I wish all these brilliant minds would work on providing unique and interesting Internet content, which is the part that is sorely needed now.
bxxp... i dunno, i kinda like the alternative - "beep!"
--
DeCSS source code!
you must amputate to email me.
--
you must amputate to email me
i read all replies to my comments
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.
The main reason I like it is because its one of those protocols where you can just telnet to a port and type and you can do something useful. SMTP is similar, as is IRC, whereas FTP you need to set up netcat or something to listen. (Its also more complicated)
I doubt it would be practical to talk directly to bxxp. Plus, it seems to be jumping on the XML bandwagon.
-Yarn - Rio Karma: Excellent
is extra overhead really an issue? compared to the amount of data, the overhead of the protocol is minimal (in terms of both processing time and connection speed). on top of that, as we move to broadband for the web, the protocol size and complexity becomes even more insignificant.
Look! They've already raised $12 million! This must be an internet con! Just watch out for their sponsorship of some reunion concert....
Seriously, this seems like good-looking technology, but I don't think file transfer is a good application of it - with file transfer, you want packets to be as bare as possible, with as much data as possible. No XML wrapping.
It will be interesting to see if all these highly intelligent people can get together and make money.
__________________________
"Oh, you hate your job? There's a support group for that, it's called everyone, they meet at the bar."
The possiblity of sneaking past router filtering, and the enhanced privacy support. Add the peer-to-peer aspect ...
Sorry, it just sounds hilarious. :-)
.org or .net sometimes too! Makes you wonder how many of these people even know about places like lyrics.ch.
IMHO, I think we're in too deep to get away from HTTP completely, though if it was integrated into the browsers smoothly, noone would complain.
Think about it, how many people are on the web that don't even know what FTP is compared to HTTP? Their life revolves around http://www.whatever.com, and they even have troubles with
... whereas FTP you need to set up netcat or something to listen. (Its also more complicated) ...
Telnet is a very handy way of diagnosing FTP problems. If you're not happy with setting up listeners for the data connections, use PASV instead of PORT.
I'm all for protocols with which you can do this -- and FTP is one of them!
Unfortunately, the need for secure protocols is going to make this more difficult as time goes on. Don't expect something like OCSP to be human-readable.
--
C: REQ . 1 14 94 0 />
C:
C: <start number='1'>
C: <profile uri='http://xml.resource.org/profiles/sasl/OTP'
C: </start>
C: END
Longer, more complicated examples are shown later, but this pretty clearly illustrates there probably won't be significant overhead.
Slashdot quality declines as the number of hot grits posts decreases. - Provolt's Law, Apr-09-2005
I just say ``ooo'', as in the first sound you make if you say the word ``water'' with the first phoneme extended. Works OK - everyone understands what's meant by it, any road up.
--
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
As much as I dislike the Microsoft business practices, I wouldn't say they abused Kerberos. They worked within the letter of the spec alltough I think the Kerberos team was expecting whomever used the ability to extend it would release that information back to the public.
"Fighting the underpants gnomes since 1998!" "Bruce Schneier knows the state of schroedinger's cat"
You can run both VNC and X11 inside a web browser using Java these days - not that I see a need to do that.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Yes, but this was fixed in HTTP/1.1 with persistent connections. The RFCs have recommended it for three years. That's a lifetime on the web.
Nope, never seen it before, at least in NJ :)
Blocks Extensible Exchange Protocol - B.E.E.P. Pronounced "beep". But what did they call it? B.X.X.P. Pronounced "bee ex ex pee" or perhaps "eggs", just to exclude a few more people.
I think part of the reason HDTV and IPv6 take so long to be adopted is because they affect existing established standards and, in some ways, have to be accepted all-or-none. When you decide on the HDTV standard or the IPv6 standard, everyone has to accept it at once (or you have to spend extra time working out a way that not every one needs to accept it at once). These entail technologies that affect existing users. However, in the case of BXXP, I expect that it is more of an add-on. You can have a BXXP-capable client without any BXXP-capable servers without affecting existing HTTP support. Conversely you can have BXXP servers without yet having any clients implementing BXXP, and as long as the existing HTTP servers are still up, no HTTP service is lost. You can't however, have a TV station broadcast an HDTV signal instead of a standard TV signal on its reserved frequencies, and then expect the standard TV service to be unaffected. My understanding is that it took a good deal of work to make HDTV service not affect existing sservice... and then to coordinate efforts with the FCC etc.
So at this level, something like BXXP should be easier to adopt.
(Just couldn't resist :)
It sounds to me like they're recreating what IIOP provides, and with the added cost that you need to encode data in the rather wasteful XML format.
I half figure that someone will eventually build an "XML over IIOP" scheme that will allow compressing it.
The Casbah project's LDO provides another alternative.
If you're not part of the solution, you're part of the precipitate.
Actually, we could build something significantly better than the Snow Crash Multiverse with current standards (i.e. Ditch the major security holes everywhere)
Yeah, no kidding. Anyone else ever think it's funny how programs in the cyberpunk genre have complex GUIs for their security holes? I mean slashing through ICE with claws and blades? What the hell does THAT actually accomplish code-wise, especially when it's all done with generic interoperable third-party tools?
--
I wish I could turn off the auto +1 w/o enabling cookies and logging in...
If it's for-profit but free, you're not the customer -- you're the product (e.g., the Slashdot Beta's "audience").
I did. When I hit "reply" there weren't any. Guess I should submit before browsing the rest of the headlines...
The Signal/Noise ratio can be improved in two ways. Remaining silent is the OTHER way.
Anarchy Online.
And I looked, and behold, the pokemon all spontaneously combusted.
... that we're going to have to actually use the header "bxxp://".
I mean, for people who just surf around, I'm sure IE and Netscape will quickly adapt to be able to fill that in themselves, and that just typing "Yahoo" will be enough to find either bxxp://www.yahoo.org or http://yahoo.com depending on how the defaults are set.
But for those of us writing CGIs, this kind of sucks. Sometimes the "http" has to be very explicit. It's a simple matter to know when to use http://, ftp://, telnet://, etc., because the protocols are so unrelated, but with these related ones, it will be a headache.
Of course, if bxxp can handle http, I guess this problem shouldn't exist at all. It still will.
"Beware he who would deny you access to information, for in his heart he deems himself your master."
It seems odd to me that we should have to embrace yet another protocol in an effort to web-enable everything. What ever happened to opening a socket and sending the info you need? TCP/IP seems like a fairly reliable data transport, and if your app uses XML packets internally to represent data, all you need to do is stuff the data into a stream and you're done. Why is it that we need a thousand different protocols for the coffee pot and microwave? Let the devices that need to be connected have their own IP stack and DHCP, and for God's sake, leave my microwave alone!
</rant>
LOAD "SIG",8,1
LOADING...
READY.
RUN
Well, I'll give him a few years to claim it. I'm positive he invented this one.
The only purpose of BXXP is not to replace HTTP. It is just one of things that BXXP can do. BXXP is a protocol framework.
---
For example, a webpage may contain 4k of text, and say, 20 2k images. Why make 21 TCP connections, when you can make one, and send the whole page in one XML stream? That is a big overhead savings, and the page will load MUCH faster. Even for something like slashdot comments, where there's about 200k of text and maybe 10 images, that's still a savings, although not as much.
Simply bandwidth wise, (assuming 0 RTT), a TCP/IP segment header is 40 bytes. A connection requires 3 packets + 4 to disconnect = 280 bytes per connection. An sequence of XML tags would probably be smaller, in addition to reducing wait time and processor load.
---
I am the dot in slashdot.org
Alright, I know this is bloody silly, but why not call it B.E.E.P. ? Why do they have to put Xs is there?
It's easier to pronounce, and doesn't sound like a trash compactor speaking Klingon ("Bee ex ex pee colon slash slash"...)
Just my little useless gripe about all the hard-to-pronounce acronyms out there on the net...
I really like this idea. From my understanding of the article, it seems that BXXP will be a "wrapper" for any file types (like HTML is a "wrapper" for plain text). This could allow us to properly embed all sorts of data within a nice, formatted page. Also, I hope that the BXXP standard will be powerful, extensible, and well documented. I would really hate to see more of the same browser-specific tag silliness that plagues Netscape and Internet Explorer. It's interesting to note, though, that if this really flies, then we may be in for another round "browser wars", especially if BXXP replaces HTTP.
Article quote: Instead of creating a metadata-specific protocol, he built BXXP as a general-purpose foundation upon which he could stack a metadata protocol he calls Blocks.
So, it's a metametadata protocol. Very cool!
And as qmail is a really great MTA it's spreading on high-volume servers. ;)
For example hotmail and gmx do as far as i know use qmail.
And egroups.com appears to use qmail, too. (but i see they use some protocol called "NNFMP" internally???)
So QMTP should be useable for some servers already. I often have mail transfers with all hosts using qmail.
Debian GNU/Linux - apt-get into it.
Of course there is a performance hit. Every time we add abstraction there is some level of performance loss.
C is slower than Assembly
Linux is slower than DOS
Windows NT is slower than Windows 95
X is slower than Windows
In every case, the slower version is more flexible, powerful, and is generally regarded as better for most situations. It's quite acceptable to trade some performance for a lot of flexibility. Computers are getting faster every year, and adding flexibility and power to the underlying technologies of our system is one way in which we 'spend' that power.
And my soul from out that shadow that lies floating on the floor
"I will trust Google to 'do no evil' until the founders no longer run it." Hello Alphabet.
A lot of people say it "dubya-dubya-dubya"...
Wait...Oh no!
George W. Bush has stolen Al Gore's thunder! Gore may have invented the internet, but the World Wide Web is George W. Bush's middle name!
---
Zardoz has spoken!
Oper on the Nightstar
You can send e-mail in mime and uuencode as a hack to solve a problem of getting files from one user to annother.
It's a hack solution for a rare (but obnoxous) problem.
[Oh ok I'll e-mail you an mp3 of the audio recorded at the last meeting]
The idea of normal e-mail is to send text. Not HTML and certenly not MsWord.
Windows helps premote this problem (not Microsoft.. just an example of "one world one os" being bad.. Microsofts todays example Linux may be tomarows bad guy in this respect.. maybe some day Apple).
Basicly a user sees a file format is native to his operating system he mistakenly believes it's "normal" and sends this file in e-mail.
If he has less than a 50-50 chance of getting someone who can accually use that file then he'll get a clue and stop. But if he has a greater than 60% chance of getting a user who supports it then he'll just assume the others are losers.
For the most part it's annoying. It's not e-mail and it dosn't do the job.
Now with e-mail viruses I'd hope that even Windows users would say NO! to Windows files simply becouse this shouldn't be commen practace in the first place. True Windows makes it EASY but that is still with the idea of two executives using commen (or compatable) software with an agreed on format with an agreed on goal (such as e-mailing the database of a daily budget or an audio file of an interview in a format both sides support [such as mp3])
If both users use Windows and Microsoft office then hay thats great go for it. But if one side uses Linux with KDE Office and the other Mac with AppleWorks then it's a matter of finding a commen format between AppleWorks and KDE Office.
Anyway.. sending MsWord files as a way to send text is a bad thing. But when there is a greater than 60% chance that the guy on the other end can read MsWord files it dosn't occure that sending e-mail in acuall text will work 100% of the time.
PS. yes I throw away ALL MsWord files unread
I don't actually exist.
"For example, users can chat and transfer files at the same time from one application that employs a network connection." It's called Internet Explorer. You may have used it before.
Another approach that some fancy load-balancers use is to always give the same IP address, but fake out the packet requests using NAT or other routing tricks, or having the web servers themselves change their IP addresses dynamically. It's a bit uglier, but browsers and DNS resolvers often cache their results, so a web server might die or get overloaded but users are still requesting pages from it because they've cached its IP address - this way you spread out the load more evenly at the cost of more dynamic address-shuffling translation work by the load balancing server.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Ambrose Bierce, author of "The Devil's Dictionary" (pick it up -- it's $1 and it's funny, even 100+ years later), argued for renaming the letter "W" to "wow" or "woo".
I'm with him. "Double-yu" is too damn long to say. www is fast to type, but lame to say. But if it was "woo woo woo", that'd be funny!
Guess I wasn't paying enough attention. :)
-David T. C.
If corporations are people, aren't stockholders guilty of slavery?
Whats to stop us from taking the protocol, removing te things we hate, modify the apache release(due end of year) to match, and distributing that? Modify the Mozilla sources to support the altered protocol. Build more apps quicker that support it (the altered protocol).
If we get it out faster and wider and everyone uses the modified version first, that should go a long way to making it the defacto standard. (Almost like an inverse msft/kerberos thing, excpet we probably won't care if we can call it bxxp or not.)
penguinicide... when jumping out a window just won't do.
"DEMUXing is more work for the client at the application-protocol level."
I don't think it is a problem. Offloading work to client side is almost always a good thing ( witness javascript success.)
Does it offer the user more than they have?
:)
Or alternatively, can it make us more money by screwing our competitors out of marketshare?
Is it simpler to maintain? (XML is nasty!)
It can be if you want it to be. It doesn't have to be. It can be quite elegant, really.
What's the learning curve?
XML? If you know HTML, I can teach you XML in about 5 minutes really. For protocols, who really cares what the learning curve is? PHB says to developer, "You will support this", and once it's supported, it's completely transparent to the user. Only the developer has to bother to learn the protocol. And if they built it around XML, it probably just ain't that hard.
What's the cost to switch? (Time & Cash)
Potentially huge. Potentially nothing. Depends on who you are. For some people, it will require downloading a new version of a browser. For others, millions on new software licenses for their crappy proprietary web servers, and developing support for this in.
Can a 5 yr old explain it to an adult?
Can a 5 year old explain the latest FPS to an adult? That didn't stop their acceptance and humongous sales.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
So what you're saying is that BXXP is an abstract class, and doesn't really do anything by itself, it just exists to be "inherited" by other classes and used in that way.
Whatever happened to functional programming? Why is earth going into an OOP shithole ever since java showed up?
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
Well, if it was that simple it would be essentially useless - so why even add the 13 bytes? I'm not saying it's good or bad (who could tell yet?), but it's very likely that BEEP will be substantially heavier than HTTP. After all, it fits all the patterns for Second System Effect.
Perhaps that is the idea. I imagine there is a big desire for this kind of thing in government and big corporations. Wouldn't pushing that kind of monitoring through under the guise of being a "new, faster, more modern" protocol be the perfect way to do it?
Finkployd
What we really need is a protocol that can, upon receipt of a single authenticated request, determine the speed that the remote end is running at, and then rapidly chunk out an entire page in a single request - instead of a few images here, a few javascript files there, and don't forget the stylesheet in the LINK tag!
It is obvious we are quickly moving into a high-bandwidth network where consumers will routinely have access to multi-megabyte streams. The TCP protocol is, by design, limited to a mere 780kb/s. You cannot go faster due to network latency and the max size of the RWIN buffer. Therefore, it's obvious this protocol needs to be UDP.
Security is also a concern - we need some way to authenticate that the packet came from where it said it did before we blast out a chunk of data - as likely there won't be time for the remote host to respond before we've sent out most of the request to it by then.. so some form of secure handshake is needed. If you could make this handshake computationally expensive for the client but not the server, so much the better for defeating any DDoS attacks.
But really.. we need a reliable file transfer protocol that supports serialized queuing and higher speeds than we do now.. and that means either ditching TCP, or setting up parallel streams between each.. with all the overhead that goes with that solution.
BXXP doesn't do that, unfortunately.. and if we're going to define a new protocol, let's plan ahead?
Just a real quickie comment:(meaning I don't have time to read anything but the /. abstract right now)
HTTP/NG has been in development for at least 2 yrs (probably slightly more) and it was designed to handle the deficiencies of HTTP while remaining based on many similar principles. Multiple channels was a HUGE part of the differences between HTTP and HTTP/NG.
I'll take some time to read about BXXP and compare it to my knowledge of HTTP/NG - but just wanted to throw this out ...
Regards,
Brice.
Isn't Jabber basically an "instant messaging" ((aaahhhiiii)) system? BXXP is a full general purpose protocol, IRC/messaging is just one thing it can do well.
I mean nobody pays for client side software, well browsers anyway. So the browsers compete on features. If the servers are using BXXP then the browsers will too.
not to mention the next version of gnutella.
When someone yells "Stop" or goes limp, or taps out, the fight is over.
the humanity, oh my lord the humanity .....
"It is a greater offense to steal men's labor, than their clothes"
>Extensible Exchange Protocol (BXXP) which seems >a *much* nicer alternative to the aging HTTP (if >the IETF will give it a chance).
Soon, all slashdot articles will be composed of entirely in acronyms(probably ESR is the worst acronym. Can't you just call him by name like everyone else?) for faster transfer speeds.
Heh, saw this in an email less than an hour ago:
:)
Date: Tue, 27 Jun 2000 13:42:56 -0400 (EDT)
From: (sender deleted)
To: (recipient deleted)
According to (recipient deleted):
>
> (sender),
>
> If you are on the phone with Invisible Worlds re:
> (machine deleted), then disregard the page. Thanks.
actually with marshall rose, who owns the machine. he is rebooting to see
if that clears up a large packet loss problem.
-(sender)
It's kinda fun when you figure out who your employer's clients are.
------------------
"We can categorically state that we have not released man-eating badgers into the area." - Major Mike Shearer, UK
I really with the slashdot editors would stop just putting 10% of the story on the front page. Before you go off ranting and raving BXXP won't replace HTTP, or that it is useless because it never will, READ THE ARTICLE.
"When you're building a protocol, you have to decide how you're going to do error- message reporting and how you're going to handle the size of objects"...."BXXP solves all of that for you. Ninety percent of the [work] is done"
BXXP is more about just replacing HTTP. It is more like a protocol framework.
"BXXP is essentially a tool kit that developers can use to quickly create protocols"
The people that are ranting and raving that we don't need more protocols are giving this a limited view. Did you ever stop to think that the internet is more than just http and ftp? POP3, IRC, ICQ, Napster, etc... everything has its OWN protocol. What BXXP is going to help get rid of, is using HTTP for more than what it was designed to do... which was transfer Hypertext documents. Sure HTTP can transfer entire files now (in both directions) but that's not what it was orginially designed for. I wish I could give a better example, but it really makes sense.
---
- 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:server: SYN ACK (40)
client: ACK (40) "GET / HTML/1.0"
Hmm, only 134 bytes!
---
I am the dot in slashdot.org
Mebbe I should read the article...
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!"
Check out a draft of bxxp at:
http://xml.resource.org/profiles/BXXP/bxxp.html
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.
Exactly.
:-)
For a techonology to spread wide, it should be affordable. There is no freaking way I am foking out that much money for a decent HDTV. Yeah I know it will enhance your 'viewing pleasure' yada, yada. But to watch news for 20 mins a day my trusty SAMSUNG is good enough, thankyou.
Same deal with Home theatre systems. Unless they have some affordable version, no one except sound-heads going to get the latest system with THX processor & AC-7.
I am also sick of the technology companies charging the premium for early adoptors. Say in CPU world, if you are the first one to buy 2Ghz Intel chip, you pay through your nose. I understand the cost of R&D. But there should be a way to spread the cost, and still sell it for 19.95
How to properly abbreviate... Is it me, or should BXXP be abbreviated BEEP? Since when do we abbreviate Extensible with an X? Ever since XML came out, I have puzzled over this.
Are x's really that much cooler than e's?
Doesn't BEEP sound better?
"This is not a company that appears to be bothered by ethical boundaries."
Attorney General Mike Hatch on Microsoft
These days the W3C doesn't seem to be interested in standardizing protocols (even HTTP); they've shifted all that work to the IETF.
I don't know that the w3 will ignore a person that was a contributor to POP3, SMTP, and SNMP. These are all pretty major parts of the Internet right now.
IPv6 was specifically designed to work alongside IPv4; some people have already started using it (it's flexible enough that you can use it even before all the specs are finalized).
Do all your homegrown app protocols support TLS and SASL? Do you want to spend a month just working on the authentication part of one of your new protocols? I don't.
Although if you don't need mux, security, or any kind of negotiation in your protocols, you may be right.
I don't know if HTTP-NG ever made it to the IETF; I know the W3C was working on it for a while, but I get the impression some people realized that they didn't really know why HTTP-NG was needed or exactly what it should do, so they put it on the back burner.
If HTTP-NG ever comes back, it may end up using BXXP as its mux layer.
He calls it a framework, not a protocol:
I always liked 'Dub-dub-dub.'
If I want to be paranoid, I have the ability to pretty much move about undetected.
.com would love to have the identities of coke.com visitors for counter-marketing. I bet microsoft would love to have information on non-IE users. I bet some company pitching DSL would love to have information on people who seem to be coming in on slower modems to pitch to.
Depends on how paranoid is paranoid. You're not really anonymous anymore. There are things like the anonymizer, remailers, and so on, but due to abuse, I bet they keep bitchin' logs.
Spoofing used to be an issue, but AFAIK, (and I haven't even thought about it in quite a while) it's not really possible anymore due to bind updates. Everywhere you turn, you're being logged. Doesn't matter if it's an HTTP server, the banner ads on that server, downloading a file through "anonymous" FTP (yeah right) or logging into your own box. I don't see much anonymity at all on the web, since your IP is scattered all over the universe whenever you so much as connect to another server. If anybody knows ways to get around that, please let me know.
You can be anonymous in the sense that the server only knows that some loser on an @Home cable modem is the one who's looking up this goat pr0n or reading about ralph nader, but when it really comes down to it, you're not.
I've always wondered if anybody will ever implement some type of reverse lookup system through ISPs. I know it wouldn't be easy, but imagine something like this - you dial up, and connect to goatpr0n.com. Since they want to market to you, they send a request to your ISP's server invader.myisp.com asking which customer is connected to ISP IP hostname foo.bar.baz.dialup.myisp.com. At that point, myisp.com sends back some "relevant" information to the "client".
Or even completely different servers. I bet pepsi
In a world where companies are getting busted for backdooring their own software, people are rioting against doubleclick abuses, and you're logged every time you take a shit, does privacy really still exist? The answer is yes, but only as long as you're doing something that nobody thinks they can make money off of.
-- Truth goes out the door when rumor comes innuendo. -- Groucho Marx
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
DUH!
Sorry, I was caught up in the heady excitement of the moment.......
bun-fhuinneog agam!
The beauty of HTTP is it is so damn simple. That is why it so successful. It's simplicity and flexibility has allowed it to grow and adapt. XML may be simple but not at simple as HTTP. HTTP may not be perfect but it works. How are you going to have an efficient caching BXXP proxy. yick! the proxy will have to parse 2 BXXP connections. That is way more complex than parsing a header and just passing the content through. My only grip with HTTP is you can't set a cookie after your started sending the content. (any lazy web programmer will agree)
Citrix
Leknor
http://Leknor.com
"So many idiots, so few comets"
What would really rock is a MMORPG, like EQ, but with a sci-fi feel. I'd throw them my $10 a month at the drop of a hat. Well, it'd have to run on Linux, too ;)
Money I owe, money-iy-ay
OK, calm down. RTFM already.
HTTP will continue to be the protocol for 90% of the web, BXXP will only become useful for massive data interchange aspects, such as those for B2B exchanges.
Expect to see IE, Netscape, and Opera extensions to allow BXXP, but don't expect to see it anytime soon, at least until they start to fully implement XHTML and XML standards. I'd guess 2002 for reasonable code that works fairly well.
If you're trying to crank out massive data exchanges, you should definitely get into this; if you're trying to do a web site, especially one with lots of text content, you may never use it.
Will in Seattle
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
Yup, now here's a place where BXXP (BEEP?) will really come in useful. Lots of data transfer, lots of channels, lots of potential.
If I were Nintendo or Sega (or MSFT - hah!) I'd be making sure I was up on this spec soonest. Heck, I'd be sending people to the steering committees.
[yeah, I own Nintendo and MSFT, but that doesn't mean Sega doesn't have cool games]
Will in Seattle
Compared to the vastly superior: ...
You meant to say vastly smaller. Whether it's superior or not depends on what you want to do. For example, your sample XML had 126 bytes more overhead than the equivalent HTTP, and 126 extra bytes is likely quite acceptable when sending documents that are usually several kilobytes in length, and those bytes buy you all sorts of XML goodies that the HTTP version doesn't have. On the other hand, if your document is on the order of a few bytes and you're sending a jillion of them, you clearly couldn't accept that much overhead.
--
-jacob
-jacob
IP is a connectionless, stateless packet protocol. There is no concept of "client" "server" "connection".
BOTH parties must have be listening for IP packets. Then they send IP packets at each other. There isn't even a concept of port numbers.
TCP is designed to be client/server. Then, one party must act as a server and have a listening socket, while another tries to establish a connection with an active open. You also introduce, with TCP, the concept of port numbers, which allow multiplexing of connections to different machines, and different processes on those machines. But TCP is built on top of IP, and there is a lot of overhead that goes into establishing and maintaining those connections.
UDP is built on top of IP, and there is absolutely no concept of "client/server"*. UDP simply provides the multiplexing capabilities of port numbers and a checksum facility to improve reliability.
* You can have a connected UDP socket, that throws out packets not from a specified ip/port, but really, it's just a big hack.
---
I am the dot in slashdot.org
bxxp sounds like a good idea, and i'm sure that it would work better than http.
but... will people actually pick it up? that's the question. as is the case in the all-too-often-used example of betamax vs. vhs, a format (or protocol) is only good if people actually use it, no matter how superior it is. perhaps people will pick it up, though.
"I hope I don't make a mistake and manage to remain a virgin." - Britney Spears
But isn't XML slow ? There was remarks like these about microsoft's dotnet stuff, which also use an XML dialect for data transfers.
MS' dotnet isn't a protocol like HTTP or FTP or this BXXP, so maybe this comparison isn't justified, but, nonetheless, what can we expect about performance ?
sigmentation fault
So when's someone gonna invent the language to let people surf the net like in Neuromancer or Snow Crash?
There are four boxes used in defense of liberty: soap, ballot, jury, ammo. Use in that order.
The usual compelling content that drives every new technology.
Our secret is gamma-irradiated cow manure
Mitsubishi ad
We apologize for the inconvenience.
I think that the central idea behind the protocal is that you can provide additional layers of abstraction (for those not in the know, "libaries" and "objects") between the protocol and the programmer (hence the "extensible" part of it). This would make it easier to write programs that work in similar ways since you could embed all of the protocol work into simple functions. This would make the prototyping of programs much quicker. Always to be remembered is that more function calls mean more overhead, but if the overall functionality and efficiency is increased, this is well justified. Sounds like a great idea to me, as a person who like it when everyone is on the same page (and this would make that a lot easier when designing web apps).
Eh...
Here is another internet draft, which describes the thinking that went into the design of the protocol.
Granted, I was pretty annoyed when one of our sales reps sent three large slapstick mpegs to every employee of a small office I consult IT work for.
:)
He doesn't get to use that mail server anymore, though, so it's all good.
Why not 5 or 6 letters? heh. Who comes up with these things?
Got shack?
ShackCentral Network
Worlds best gaming network!!!
Your HTML ideas are very interesting, especially the redundant image sources.
However, BXXP is a protocol (like HTTP) not an authoring language (like HTML). HTTP and HTML have nothing to do with each other, except that they are both very popular standards for online content. Thus, your post is off-topic.
look at the amount of fun they are having getting IPv6 working. And they want to get this up and running soon? Good luck
"They said we couldn't do it [Athlon]... but we built it, we shipped it... and we didn't have to recall it." Rich Heye
Just wondering if anyone actually reads the articles. It clearly states that they're not trying to replace HTTP.
-Sigs are for losers.
...but wasn't there already a HTTP-NG standard already working its way though the beast that is the IETF?
DrLunch.com The site that tells you what's for lunch!
Why multiple connections are a bad idea ...
... a server throwing lots of parallel connections at a complient proxy will be sorely disappointed itself ...
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.
And any number of additional protocols, be they layered on top of IP (like TCP is) or TCP (like BXXP is) will not solve this problem.
Each TCP socket takes up system (kernel) resources on the server.
One way or the other, multiple connections are going to use more resources. 'Tis inescapable.
Where those resources are allocated is entirely implementation dependent, and indeed, only makes sense in terms of specific implementations. Look at an MS-DOS system, where there is no kernel, or something like khttpd, which implements HTTP inside the Linux kernel.
Layering additional protocols on top of existing protocols which do the same thing because some number of existing implementations don't handle resource allocation well is highly bogus.
The thing is, any time you flood a system with more connections then it can support (whether those connections are at the TCP level or something higher), it is going to suck mud. BXXP isn't going to change that fact; it is simply going to relocate it. See above about bogus.
Personally, BXXP looks to me to be redundant and needlessly repetitive. The core is basically TCP running on TCP, and then there is some higher level stuff that doesn't belong in channel-level code to begin with. It would be better to design some standard wrapper protocol to layer on a TCP connection to describe arbitrary data, thus providing something new without reinventing the wheel while we're at it.
dragonhawk@iname.microsoft.com
I do not like Microsoft. Remove them from my email address.
As for your 2nd question, it might as well, but that also has to do with the exact specs of the protocol, which I don't know.
You know, I got NetworkWorld mag at work today and I thought the artical on the Oxygen Project was much cooler and made me think a lot more about Our Networked Future(tm).(or visit Scientific American
Seer
This means that a firewall could conceivably be configured to parse the XML stream, and then firewall the individual streams. This also expands on the possibilities of things like the pics-rating scheme - a piece of content could describe itself in detail - not limited to those categories. Firewalls and logs could be based on this data.
OK, all well and good - but how much overhead is this going to put on the firewalls? If it has to parse an entire XML stream for each request, far too much. Sure, we'll know exactly what's being downloaded, but will your average user wait around to download it? So these kind of features probably wont be implemented.
But if it opened a new TCP socket each time, and placed any content header info right at the top, where headers belong, it would work....hmmm, does this sound anything like a certain protocol beginning with a 'H' to you?
To sum up - yes, its a great idea, but practical considerations make it a bad idea, IMHO. But who knows? Everything could change, and maybe slashdot will have to change that line below the comment box from "Don't forget the http://" to "Don't forget the bxxp://"... :)
Hmm...H-T-T-P is much easier and nicer to say than B-X-X-P. But if they just used the first letter instead of going for those X's, we could just say BEEP! Wouldn't that be cool?
beep://slashdot.org
I like that much better.
-JD
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.
Sure, TCP is already multiplexed, but there is a lot of overhead inherent in this mulitplexing scheme as TCP cannot distinguish between 10 connections to 10 different machines or 10 connections to one machine. They are all completely seperate connections, all with seperate kernel space buffers, all doing their DNS lookups, all having seperate windows and flow control and connection states, etc, etc. There is a lot of overhead that goes into making a TCP connection; it is very noticeable to the end user.
This protocol, by allowing ONE TCP connection to describe ALL transactions between two machines, can reduce overhead on both machines, and reduce load times and processing consumption. See my reply to the post above yours.
It does serve a purpose. And it is in no way a replacement for TCP. It does not provide the connection, reliability, flow control, etc, capabilites of TCP. It is a stream format, not a packet-level format, as such, it MUST be built on top of TCP, as TCP provides a state-oriented, stream oriented connection on top of a connectionless, unreliable, stateless datagram packet protocol that is IP.
---
I am the dot in slashdot.org
Could this possibly solve the IPv6 deployment problem? If everything is mux'ed over one socket, with most of the work being done above it, it would only require one socket between computers as a generic data channel.
In theory, it would only take a few OS utils to generate this connection, and apps could use it, not knowing if it was running over IPv4 or v6, and therefor one wouldn't have to rewrite the apps for the new IP protocol. Of course, you have to rewrite the apps for bxxp, so I suppose you havn't really gained that much.
Arrg. You're corrent - this is re-inventing way too much... time would be better spent fixing current protocols to be firewall friendly and such.
Ce n'est pas une signature automatique.
...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.
"The Internet is made of cats."
I'm not sure that http is inadequite for what it was designed for; what I do know, as someone else mentioned (and right on, if I might add), is that http is one of the few protocals that has been greatly expanded and stretched out in the pursuit of new web apps. When you think about the fact that this protocal was designed to pump simpe, marked up text documents over the Internet, and that it now handles dynamically generated content, binaries, Java applets, and a whole passle of other technologies, it is a miracle that it has aged as well as it has.
I would say that http does a good job of the basic work that it was designed for, and I doubt that it will dissapear from that too soon. But as networked applications grow more and more complex, http is going to be harder and harder pressed to adapt. Hopefully, simple apps will keep using the simple http protocal, and newer, more complex technologies will have access to a protocal framework with the power and flexability they need.
"Sweet creeping zombie Jesus!"
-- snip --
GET http://www.yahoo.com/ HTTP/1.1
HTTP/1.0 200 OK
Date: Tue, 27 Jun 2000 18:48:16 GMT
Content-Type: text/html
X-Cache: MISS from cache_host
Age: 0
X-Cache: MISS from cache_host
Proxy-Connection: close
-- snip --
for a grand total of 232 bytes.
my previous post was slightly incorrect; i passed a bad http request, which generated a few more headers:
-- snip --
GET /
HTTP/1.0 400 Bad Request
Server: Squid/2.0.RELEASE
Mime-Version: 1.0
Date: Tue, 27 Jun 2000 18:02:27 GMT
Content-Type: text/html
Content-Length: 811
Expires: Tue, 27 Jun 2000 18:02:27 GMT
X-Squid-Error: ERR_INVALID_REQ 0
X-Cache: MISS from cache_host
Proxy-Connection: close
-- snip --
grand total: 289 bytes.
and that's not counting the tcp/ip headers.
--
----
I think SOAP mandates the use of HTTP, though.
Other things (like ICE) would work well over BXXP, though.
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
Jeff
I remember the last article that mentioned using xml for something. Everybody was complaining about how stupid and bloated and non-universal and overhyped xml is. Maybe it was just because it had something to do with microsoft and that makes people more apt to complain. Can't say that I blame them.
Why is it only the direct3d games that won't run in w2k!?
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)
What's the point of multiplexing different data streams over a single connection? Why not let TCP do the hard work, that's what it's there for...
We have it right there - finally, a TCP/IP protocol that replaces TCP/IP! What'll they think of next? Maybe the next advance in computing technology will be emulating a 386 in my shiny Pentium III?
Replacing HTTP is a stupid thing to do because any "replacement" isn't a replacement for HTTP at all - it's a replacement for everything. HTTP does what it needs to do (and then some):
- It sends documents of any type.
- It deals with mime-types of those documents.
- If you're using a proxy, it'll even get files over FTP.
Why would we use a chat protocol (or one that can do chat) to do file transfers (which is what HTTP is all about)? Seems to me, it's trying to replace all of TCP/IP and all established protocols. We already have seperate protocols (IRC, FTP, TFTP, HTTP, RA, etc.) so why do we need what amounts to an XML wrapper around them? Someone obviously is spending too much time trying to reinvent the wheel - all because they like the sound of the letters XML - the sound of the almighty Venture Capital and Media Buzz.Discuss trolling and moderation
Tim berners lee reportedly says 'whu-whu-whu', which is fast, and fun to say too.
A fairly widely available way to get better connection setup performance for TCP is a variant called TCP for Transactions, or T/TCP (RFC 1644). This allows you to e.g. set up the connection and send the HTTP request all in the first packet. It's been in BSD for 5 years, but software has to be written slightly differently to use it and most software isn't, so T/TCP isn't widely used.
BXXP is no more a replacement for TCP/IP than an API is a replacement for the underlying system. As the article said, the purpose of BXXP is to serve as a toolkit for the development of higher level protocals that can piggyback on the existing TCP/IP infrastructure. What it is there to do is to give developers a way to create new protocals for complex applications, without having to reinvent the wheel everytime they want to build a network aware app. It's a tool, so that every time you write network software you don't have to fiddle with low-level details of bitfields and error checking when you want to create a way to let multiple applications talk. I think the "replace HTTP" angle is being overemphasized. That doesn't seem to be the primary purpose of this tool- it has some uses that might be related to giving some new functionality over and above http, but it has a lot more flexible uses. Existing protocals are not appropriate for every application; if there is a good framework for building custom communications methods, why try and shoehorn a square into a circle.
.
Man I love mixing metaphors. .
"Sweet creeping zombie Jesus!"
One thing I like about HTTP and POP3 (and some
other protocols) is that I can just telnet into
the appropriate port and type the commands if I
want to. I actually check my mail this way fairly
frequently.
BXXP may complicate this.....
Tweet, tweet.
As it stands, with SOAP and other XML-based protocols coming down the line, there is actually very little real need for BXXP. There is little demand for mutliplexing mutliple channels over one TCP connection...and it looks like that is all this protocol really offers.
The protocol might be a good one. It's tough to tell from the article. (personally I'm skeptical of anything that jumps on the XML band wagon lately)
However, it's not going to replace HTTP for the following reasons:
Lets be realistic here - Invisible Worlds does not have the market power to create a de facto standard, and the W3 is likely to ignore it - they're busy trying to get SOAP to do pretty much the same thing.
BXXP over IPV6 serving up some .PNG/and .MNG's.. yessuh.. the day of the new acronyms and extensions is upon us. Repent Sinners! Burn thy gifs, to be accepted into the geekdom.
--
Insert Witty Sig Here
More reasons why MUXing can be a bad idea:
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.
it will be interesting to see some http vs. bxxp benchmarks whenever there is code behind it.
--
I like simple protocols/standards with no possibilities for extensions. Look at history:
Kerberos: It has a field which is reserved. The standard was abused by MS, and the extension is now a "trade secret" making "MS-Kerberos" a property protocol.
SMTP mail: Can be extended with X- headers. Used is many incompatible manners by diverse email software.
HTML: A standard which is designed to be easy to extend. Need I say more ?
Keep the protocols simple with no possibilities for extensions, and make sure that implementations don't fail gracefully when abused. If so, all implementations will work together, and MS and other will fail when they apply their "embrace and extend" tactics.RFC1925
It's a rather interesting article, but I'm gonna have to say that it won't be replacing HTTP anytime soon like some would like to think. Whether we like it or not, the Internet is based upon commodity protocols (some are getting quite old yes, but their usefulness is still rather high) that work rather well in their niches when you look at the limitations that are placed upon them.
The Net community as a whole isn't going to up and replace a tried and tested protocol with some new upstart just becuase the designers claim it is better. After all, haven't we seen this before with the marvelous new construct known as JAVA? And what was JAVA's fate, again?
I'm not surprised multicasting hasn't caught on, and I think the reasons for it are economic. With multicasting, no matter how many users your site serves, you only need a low-end server and a slow network connection; it would be difficult for the web hosting company to extract a lot of money that way. On the other hand, if you send a separate stream to each client, you need a high speed connection, and you need to pay for it. Thus, I think, the economic incentive for web hosting companies is not to install multicasting support.
I don't understand the advantage of "channels". Is this just so you don't have to open a new socket?
I might also note that putting all these channels into one big pipe makes it harder for a user (or administrator) to block something--or even know it is there. For instance, what if RealAudioBxxp devotes a channel to sucking data from my harddrive? With HTTP I'll see another connection being made and I have to option to block it. With BXXP--no such luck?
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
TOR himself was at the IETF presentation, wonder when we'll have an O'Reilly book on BXXP?
.sig
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)
Unless they shoehorn this into the mainstream, I have doubts that it will catch on. The newly net-enabled techno-romantics have grown up seeing http://... - making the change to the (imho, unweildy) bxxp:// will not be easily done.
Coming soon to an internet near you:
bxxp://stallman.fsf/index.xml
...brave new world, I guess.
this is a sig.