Slashdot Mirror
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?"
I've also been disappointed with the lack of uptake on BEEP. It's a very cool concept.
BEEP is Blocks Extensible Exchange Protocol (RFC 3080). More details can be found at here.
When we were designing RTSP, we looked for something like this, and at the time, the options weren't very appealing. We ended up using HTTP as a quasi-base protocol. I think it was the best solution at the time, but had BEEP been available, we'd have used it in a heartbeat.
By and large, yes... it's a symptom of the needs of applications being so varied.
(warning: blatant plug follows) For what it's worth, however, I've developed mine over the course of three years and a dozen or so projects, to the point where I think it's pretty mature and useful; it's open source, and portable to most environments, although the IETF has of course never heard of it... ;^)
I don't care if it's 90,000 hectares. That lake was not my doing.
BEEP came to life as BXXP at Invisible Worlds a few years back, where I was an executive. Our goal for a while was to use it to federate heterogenous search engines. Invisible is no more, but the protocol lives. A lot of thought by people with a great deal of Internet architecture went into it... but I'm not about to pass judgment on whether or not that's a good thing!
There are a couple of (significant) differences between BXXP and BEEP, but no fundamental changes. And the name change came about as a result of commentary from folks at the IETF session on the topic. It appears they were tired of the eXcessive use of the letter X, that and BEEP is easier to say.
The BEEP activity I noticed most recently was on a proposal for syslog-reliable, and I believe there are some intrusion detection things using it in the academic space.
There is also an excellent white paper (on beepcore.org I think) on the transport of SOAP using BEEP rather than HTTP, and it really is a pretty sweet fit, though early on they were in competition for mindshare at the IETF and neither wanted to be absorbed conceptually into the other.
O'Reilly has published a book on BEEP by Dr. Marshall Rose, the principal BEEP designer. It's good.
Sweetums
------------------------
Jack not name, jack job!
NO!NO!NO! Application Programming Interface!
UDP is great for DNS since queries are small and the overhead of using TCP is large compared to the data exchanged. UDP is also great for things like cache servers using ICP, since then you only need one socket descriptor that can serve however many sibling/child caches you have.
From RFC 768, entitled "User Datagram Protocol": The RFC is two pages long (as opposed to RFC 793 -- TCP -- which has 84 pages) and explains that it is simply a packet of data that does nothing but carry data. It does no handshaking in the protocol, and does not establish a connection, and is thus connectionless.
BEEP's an impressive protocol framework with even more impressive implementations.
I'm using it in a burgeoning open source project because of it's ability to multiplex bidirectional communication channels in a transparent fashion. Other features such as dynamic client/server roles, authentication, and channel encryption are just icing on the cake. The less I have to muck around with protocol state details the better!
When I first started looking at BEEP I was impressed by the spec but I was suspicious as to the quality and breadth of implementations. After looking through the high level Java abstractions and more specifically BeepCore-Java I was able to throw together a workable protocol that's proven to be extensible and quite robust in just a few days.
The BEEP community is alive and well!
There are a number of opensource BEEP implementations:There's an excellent IRC channel at OpenProjects with the kitschy name #beepnik.
There's the obligatory O'Reilly book, BEEP: The Definitive Guide.
But the best source for information is the Beepcore.org site which has, among other things, an excellent whitepaper on the justification and design of the BEEP protocol.
first, i'll apologize for running beepcore.org on a small server
/mtr
combined with tomcat. (if someone has some hints on making
netbsd/apache/tomcat run more robustly in the face of significant load
-- or if you can tell me how to get the thing to fail gracefully instead
of tossing its stack -- please drop me a private email -
mrose+mtr.slashdot@dbc.mtview.ca.us - thanks!).
second, i have to praise this post for the way it seemlessly blends a
little bit of truth, a little bit of wisdom, along with a healthy amount
of ignorance and untruth. (my favorite untruth: marshall as the OSI
guy. the actual truth: marshall killed OSI in the IETF on November 4th,
1993 with the "roadkill in motion" speech.)
it is easy to agree with the fact that beep suffers from both political
and technical hurdles. as usual though, folks can disgree on the actual
details.
on the technical front: the beep specs use DTD not schema -- there
aren't any schema fragments in either rfc3080 or rfc3081, you must be
thinking of something else. the choice of DTD over schema is simple:
DTDs are ugly, but schema sucks. that explains why everyone has their
own pet language for defining the acceptable syntax of an XML
document. if schema was a winner, we'd be seeing fewer alternatives
instead of more.
everyone has their own "main complaint" about http. i hadn't heard the
verbose encoding one before, but maybe we should ask Keith Moore to add
it to the list (cf., rfc3205).
certainly, there's a lot we can agree on with respect to the political
front, so i'll just focus on the part we don't agree on.
the actual consumer for beep is the ietf. there used to be this joke
that the apps area invented cloning, because all working groups formed
argued exactly the same issues, over and over and over again, regardless
of the problem to be solved.
with beep, no one gets to argue those things any more (e.g., how to
frame packets), instead they get to go off and presumably argue things
specific to their application domain. (if folks want to understand the
reasoning behind this, check out rfc3117.)
the sacred working group, that you're so pissed off about me cutting
into, is a perfect example. a bunch of guys focused on security issues,
trying to write an application protocol. sorry, wrong skill set.
contrary to popular belief, i don't need to go looking for trouble. in
this case, it was a couple of ADs leaving an early sacred meeting,
shaking their heads, and then asking me to beat some sense into some
folks.
if you're unhappy that i stuck my nose in your business, then all
i can suggest is you get more clueful in the application design space,
so "the management" doesn't feel they have to go out and get you
help. particularly help that you don't like, and especially help that
would rather be doing other things with other people.
beep isn't research. it's a "best hits" collection of stuff dating back
to 1981 that's known to actually work. the only new part of beep is that
it got integrated into one coherent spec. and that's the reason that the
iesg approved it after only a year. they were familar with what it did,
how it worked, and they had a problem.
of course, you are perfectly free to attribute this to an "old boys
network" (i'm sure allison would appreciate that). when i find the
actual "right wing conspiracy", i'll be sure to sign up. it will
certainly reduce my frustration in dealing with the 100's of procedural
hurdles that get thrown in my way at the ietf.
finally, as far as web services go, well, let's just say that those guys
could learn a lot from what xerox did back in the early 80's. in a few
years, they may actually have something that works half as well as what
xerox did...
sorry, but BEEP only specifies XML for use on the control channel, that is setting up and tearing down the initial connection and any new channels. an ad hoc parser is sufficient for this purpose. any application layered over BEEP is free to use whatever data format it wants.