Will BEEP Simplify Network Programming?

hensley writes "There is a (not quite) new effort by the IETF to standardize a framework for network applications, called BEEP, the Blocks Extensible Exchange Protocol. Standardized in RFC3080, it takes care of all lower level tasks an application level protocol has to like framing, authentication and capabilities negotiation in a modular and lightweight way. In the current issue of Internet Packet Journal (a quite nice and free-as-in-beer technical publication by Cisco) is a well written Introduction to this framework. Why isn't anyone adopting this protocol besides some Java libraries like beep4j and PermaBEEP and a C library called RoadRunner. I couldn't find any applications based on this protocol, regardless of it's promised capabilities. Is everybody still inventing his own application layer protocol?"

Comments

well

[mindstrm]

Why do you assume we should have ONLY ONE application level protocol? There is a REASON that the Internet is based on IP, and not, say, TCP only. or UDP.
Or GRE.

Or anything else we have yet to invent.

Because we don't yet know the best way to use the network.

Maybe we haven't adopted BEEP because you don't just 'create' a standard by declaring your stuff is better. Maybe it's because peopel ALREADY know how to do regular socket programming.

Who knows.

XML is too much sometimes

[Pauly]

I've played with BXXP/BEEP, and it is quite cool. Truly amazing P2P applications should be sprouting from its vines. However, the application that should be it's shining glory doesn't use it: Jabber. There must be someone out there in the jabber community that can expound on this.

Hanging my head in shame, I'm one of those "still inventing his own application layer protocols". ASN.1 and RPC were also supposed to save me from doing this. Lately, I've found I've been implementing my own protocols using the concept of netstrings to suit my admittedly low-level needs better. Sadly, as XML and its derivatives mushroom in complexity, I find them less appealing.

Re:XML is too much sometimes

[dmiller]

> the concept of netstrings [cr.yp.to]

Only Bernstein could think that an ASCII representation of Pascal strings is original.

Re:XATP, web services + pipelining

[ebyrob]

to erase the TCP connection negotiation overhead.

Isn't this why UDP and other protocols exist on top of IP (or other routing layers). So you can forgo the overhead that a fancy session layer (like TCP) incurs.

It seems to me that most of these new protocols are just trying to get a free ride through existing firewalls... Why can't we all just use IP the way it was meant to be used? (and move to v6 to alleviate addressing pinches)

GOTOs Represent!

[Anonymous Coward]

I despise people who wont admit the usefulness of GOTOs.

I once wrote a 2000+ line RPG without a single loop or set of code blocks in C++. (ie: I used GOTOs instead of brackets)

It ran beautifully, and still does. Not a single error in the whole thing.

I've seen others write a similar game using loops and code blocks, and watch as it hit infinite loops, memory errors, and whole hosts of other problems easily solved with a GOTO.

Say what you will about GOTOs being outdated, but when you compile a C/C++ program, all your if/else/loops all compile into GOTOs.

If they were useless, they why are they still included in all chips? (and prolly will be forever)

What about the bandwidth cost?

[I Prefer Dannii]

Good to see that this protocol is as bandwidth efficient as most of the rest of the IETF protocols. Ahem.

Re:Not so impressed

[Twylite]

I'm sorry, but I can't buy much of this at all.

BEEP is a ridiculous waste of time which equates to XML-encoded-TCP over TCP/IP. The many unsubtle problems that causes should be obvious; if they aren't, here are some:

• Multiple channels to a single endpoint: typically not useful without routing; few protocols require multiple data bands, and those that do usually require QOS in at least one band, in which case you want separate TCP/IP connections where QOS will (hopefully) be supported by routers between you and the server.
• XML protocol headers: Adds a massive amount of bandwidth and processing overhead, which achieve little if any benefit over a binary encoding. Contrary to popular bullshit, XML is not human readable (as if computers care about that), is not fast/efficient and is not programmatically simple to decode (2 grammars, 2 character encodings, 5 syntactically different data classes, and 2 orthogonal data models all in once specification with more BNF rules than C++!). The XML spec. states explicitly "Terseness is of minimal importance..." - certainly NOT what you want to use as header data on packets in a communication channel.
• Security: BEEP proides just another mechanism for hiding attacks, and requires a new application level firewall which must feature a full XML parser (in order to monitor and firewall individual channels within the protocol). Not only that ... you think that Unicode attacks are bad? With several years of development behind them, MS XML parser and Xerces STILL aren't fully XML 1.0 compilant -- how many security compromises do you think may be present with all the encodings XML supports, and how many will be present in the hundreds of less mature products?

You point out that SGML is a bad thing for encoding "at that level", but in the same breath say that XML is a good thing. Since XML is SGML-compatible, and largely employs the same syntax (but doesn't allow SGML short-cuts like leaving out closing tags), I fail to follow your argument.

And in your musings about the IETF, has it ever struck you that maybe the IETF also think that adding an incomprehensibly slow transport layer on top of an existing and widely supported transport layer is a shit idea? BEEP is NOT an application level protocol, even if it wants to claim to be one.

Re:Annoyed

[anshil]

I'm completly sharing your visions.

XML maybe very cool and ideal to store data, for config files and all that. How cool would be a completly XML based /etc directory?

However I don't see any real benefits for protocols.

In example what does XML-RPC do any good? Is conventional RPC suddendly uncool? What can XML-RPC do, what normal RPC can't? Except that it uses 5 times more bandwith.

It's just sad, if you type RPC in google, the first five links you get is all about XML-RPC. So marketing words can boost a whole technology? Nobody seems to remember what RPC itself is, and a lot of developers mismatch it today if you talk with them about RPC, you say hey why don't we use RPC? Instead of stuffing sockets ourself, and they start to talk about XML, RPC does not need XML at all.

Re:Annoyed

[ceswiedler]

The best use of XML is when you DON'T have control over one of the ends. B2B applications can benefit greatly from DTDs/schemas and aren't going to care about bandwidth issues as much.

The "classic" example for an XML based protocol is a server which provides weather information to anonymous clients over the public net. Do you want to write your own protocol and try to explain it to everyone who wants your information? No, just package it in XML, provide a schema, and it's easy for clients to fetch.

Situations where you DO have control over both ends don't benefit from XML very much, especially when performance is important (and when isn't it?).

There is a place for technologies which consume extra CPU, memory, and bandwidth but provide something else: for example, reduced programmer development time (for some applications). Java is a good example. The benefits of XML are more limited, but they do exist.