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?"
Am I the only one who thinks that acronyms that are normal words just confuse non-technical people?
I mean honestly, I've seen people get over RAM and SDRAM but when I tell them that there's a problem with the BEEP they are going to just flip out.
And I appreciate the kind folks at slashdot for posting it!
-- Mao Zedong, Esq.
Is a simple question mark too much to ask for?
It's hard to be religious when certain people are never incinerated by bolts of lightning.
It strikes me that this protocol doesn't handle multiple connections to different servers/peers aka Kazaa/winMX, no authentication that the data being transferred is accurate aka Freenet, so why adopt such a protocol? If all you're going to do is re-implement these ideas on top of this B.E.E.P. stuff, really, what's the point?
the electricity over IP rfc
why run from Vincenzo?
I used beep in a programming course in High School. Unfortunately, every time I used it people shouted "nosound!".
It strikes me that being the first to implement a protocol is risky. What if nobody else implements it. What if it is trashed all together? What if it is shown that it isn't all that great after all?
Get a few big companies to use it and watch the rest follow.
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.
Sounds like a cool idea, however many programs need specialized network code to function efficiently. Most things are either done completely from scratch, or over an already established protocol. My dynamic DNS service just uses an HTTP request to update my records, and thats plenty easy. It could use BEEP but there isn't a whole lot of need. I think it is best used where it makes sense, not EVERYWHERE just because its a cool idea.
This way RoadRunner goes really fast with
MEEPMEEP!(thp-thp-thp-thpppp) this was all just a funny lie
Mordor...a magical, mythical land where women are more rare than dragons--but where every man would rather find a dragon
Now I know I can stay up all night to code get High on Caffine (mnt dew) and sleep in as long as I want, and I will live a longer life.
I love it
keanmarine.com
As soon as I start working on it again, of course. If anyone wants to lend a hand, feel free.. ;)
-- "So, what's the deal with Auntie Gerschwitz et all?"
The most interesting use for BEEP that I've found so far is iCalendar's Calendar Access Protocol (CAP).
When I first tried to access the page I got error 500. This site could go down soon me thinks or atleast the java server pages seem to. (usually the first things togo when /.ed) So here's a hard link to their beep description.
Here's a slashdot story from just under two years ago on this exact protocol. Only at the time, it was named BXXP. Haven't heard a peep about it since.
So, has anything changed since then? Is the protocol the same as it was then? Has anyone used this technology for anything?
This protocol seems like a very nice complement to XML-RPC and SOAP-- XML-RPC for simple, one-way, message-based communications, this for complex, two-way, stream-based communications. Why haven't people recognized it as such? What's going on here?
I am writing with my cool letters. æåø®ð Hope it is okey.
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.
Is everybody still inventing his own application layer protocol?
Stateless, connectionless servers are a good idea (HTTP, NFS, SMTP); for this reason, most people are going with web services calls (XML-RPC or SOAP) and using HTTP pipelining to erase the TCP connection negotiation overhead. This solves 95% of the problems that BEEP is designed for.
If you're still convinced that you really, really, really need a stateful connection, XATP is much simpler and gets the job done just as well as BEEP.
Error: 500 /beepcore/home.jsp
w ClassName(JspCompiler.java)e r.java)( JspEngineContext.java)p Servlet.java)s perLoader.java)e rvlet.java)a pper.loadIfNecessary(JspServlet.java)a pper.service(JspServlet.java)l e(JspServlet.java)e rvlet.java)t .java)e rvletWrapper.java)v a)v letWrapper.java)v ice(ContextManager.java)t extManager.java)o nHandler.processConnection(Ajp12ConnectionHandler. java)o olTcpEndpoint.java). run(ThreadPool.java)
Location:
Internal Servlet Error:
java.lang.NullPointerException
at org.apache.jasper.compiler.JspCompiler.generateNe
at org.apache.jasper.compiler.JspCompiler.(JspCompil
at org.apache.jasper.JspEngineContext.createCompiler
at org.apache.jasper.servlet.JspServlet.doLoadJSP(Js
at org.apache.jasper.servlet.JasperLoader.loadJSP(Ja
at org.apache.jasper.servlet.JspServlet.loadJSP(JspS
at org.apache.jasper.servlet.JspServlet$JspServletWr
at org.apache.jasper.servlet.JspServlet$JspServletWr
at org.apache.jasper.servlet.JspServlet.serviceJspFi
at org.apache.jasper.servlet.JspServlet.service(JspS
at javax.servlet.http.HttpServlet.service(HttpServle
at org.apache.tomcat.core.ServletWrapper.doService(S
at org.apache.tomcat.core.Handler.service(Handler.ja
at org.apache.tomcat.core.ServletWrapper.service(Ser
at org.apache.tomcat.core.ContextManager.internalSer
at org.apache.tomcat.core.ContextManager.service(Con
at org.apache.tomcat.service.connector.Ajp12Connecti
at org.apache.tomcat.service.TcpWorkerThread.runIt(P
at org.apache.tomcat.util.ThreadPool$ControlRunnable
at java.lang.Thread.run(Thread.java)
When information is power, privacy is freedom.
Simple !
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.
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!
Ironically, the layer at which my application specific needs are met? Yes, I am still writing that particular layer.
I don't think I'd trust a network protocol that has a web page that isn't even consistently viewable. Writing HTML is a lot simpelr than network programming, after all.
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.
The functionality apparently provided by BEEP sounds similar to one aspect of the functionality that .NET is trying to accomplish - namely ease of network connectivity and data exchange. I wonder if .NET goals played any part in the design of BEEP.
No state is maintained from one HTTP connection to the next, nor from one SMTP connection to the next.
I think it's pretty funny that the only message in the July mailing list archive for Road Runner is from that spam-bitch, "Christine Hall."
2 002-July/thread.html
List:
http://lists.codefactory.se/pipermail/roadrunner/
(codefactory is the company working on GtkHTML and Mr. Project, btw).
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I looked at BEEP early on, when it was called BXXP, for doing RPC calls. At the time we decided that SOAP over HTTP was the better option for our application. I think that the world has moved on since then, today I would design using REST principles and HTTP, and take advantage of Apache. For applications requiring something more 'stateful' I would probably choose Jabber, which is reasonably well established, over BEEP. BEEP will have a hard time competeing with established extensible protocols which do, if not an excellent job, a good enough job for most applications.
The idea is to introduce as little channel state (as few nested channels) as possible. BEEP is essentially "TCP over TCP".
with two example applications!
www.advancedreality.com
I'm assuming that this is a troll... you let your secretary update her own machine? Did she also double as your system admin? If so,then give her credit for that. If not, you might have other problems. If it looks like a troll, acts like a troll, and sounds like a troll it probably is a troll.
Damn, for a minute there I thought it was a post about the Beeb (the most wonderfull piece of computer hardware ever to come out of the UK, also known as the BBC Micro to the un-initiated).
Oh how it takes me back. The days spend on the old Beeb, learning to program (in basic!) and playing those wonderful old games. I feel quite nostalgic about the old Beeb.
Ah shit! Did I just admit that I actually learned to program on a BBC Micro? Dammit. There goes all my credibility. Nobody on Slashdot will take me seriously anymore! I can just hear the comments: Shutup Grandpa... go play with your 8 bit calculator Granpa... I have a question about Basic Granpa... what does "goto" mean Granpa...
People couldn't type. We realized: Death would eventually take care of this.
---
I have trained slashdot moderators to moderate my posts according to the subject
BEEP's main proponent, Marshall Rose was one of the main wheels in the OSI project. So much of the initial buzz came from his name alone. People were talking about the protocol before they read the drafts (oh yes that is normal for the IETF).
I do have a bunch of quibbles technically. First using XML is a good idea, Using the obsolete SGML DTD mechanism to describe the protocol sucks. I think Marshall started to suplement the DTD with schema fragments but that makes things worse, not better, we now have two specs in one document, the schema version which is what people will implement and the DTD version which is normative.
The other problem is that SGML is a real baaad choice for an encoding at that level. The main complaint about http is that the encoding is too verbose leading protocol exchanges to require multiple round packets instead of one. BEEP does not address that problem.
Politically BEEP has bigger problems, first being that IETF does not have as much influence as it might appear when it comes to promoting new protocols. There haven't been very many IETF protocols that started in IETF process and took off like wildfire in the past ten years. HTTP took off and was brought into IETF process, same with TLS (SSL). Most successful IETF protocols had a userbase before the working group was formed.
The problem with BEEP is that Marshall did not start with a constituency who had a problem that BEEP was the solution for. Instead he wrote the protocol and then went off looking for consumers. So we start to see Marshall popping up at random in working groups like SACRED peddling the BEEP Kool-Aid. The problem being that if you are doing a researchy protocol like SACRED the last thing you should be doing is layering it on someone else's research.
After this happened a few times Marshall started to alienate folk like myself who might be interested in BEEP as an option but certainly were not going to allow him to insert himself onto our critical path.
The other problem is the nature of the IETF these days. The problem is that they talk a good talk about being open and such, but it is really an old-boys club. The old-fart faction is strong on the IESG and IAB, they have known each other for 20 years and they don't want anyone messing with their turf.
In theory the IETF process is open. In practice there are a bunch of shadowy cliques who make the real decisions in private. BEEP got to RFC status in record time because it was proposed by an IETF insider. Problem is that the IESG does not have much influence with the people in the Web Services world which is where all the interest in XML based protocols is at the moment.
Most of the people I see at W3C and OASIS Web Services meetings have no IETF experience at all. Of those who do, none are IETF insiders and so an endorsement by the IESG does not have much force.
For BEEP to take off it really needs an endorsement by one of the heavy hitters of the Web Services world which basically means IBM. Microsoft or Sun. I don't think that is very likely because everyone knows that there is a lot of work to be done to make Web Services work and there is simply nothing to be gained by putting BEEP on the critical path. People are more interested nailing down WS-Security, SAML, XKMS, geting WSDL to work and such.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster@dbc.mtview.ca.us and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
Apache/1.3.20 Server at beepcore.dbc.mtview.ca.us Port 80
Way to go, BEEP! I won't fuck with you anymore, because I'm no pedophile, OK?
If you spend all your time writing your own complex language parsers for XML or HTTP, you've MISSED THE POINT COMPLETELY.
No by definition the aplication layer protocol provides the application with access to the network stack through an API.
Um... You remember what API stands for right? That'd be "Advanced Programming Interface" or some variation. If you'd ever had to code using one of these, particularly a "new" one, you'd realize that "Interface" is a very relative term.
So, is it easier to just use sockets as your application's API to the network? In many cases yes... Interestingly enough, TCP already provides multiple streams of cummincation, and port numbers are supposed to tell you how to behave when listening or connecting. Adding another layer on top of this to do essentailly the same thing seems redundant. The only benefit I can see to this might be effects on performance(for wireless) or the ability to "sneak through" firewalls. But at what cost complexity and efficiency?
That said, if anyone ever comes up with a useful presentation layer, I'd be happy to give it a whirl. (XML has been kind of fun that way...)
i believe part of the EPP draft deals w/ using BEEP as a communication layer.
.biz registry wanted to do an initial roll out of this when the tld went live, but there was a lot of push back from the registrars b/c of timeframes and "newness".
the
-Jae
How long before AOLTW either buys the RoadRunner library or sues the makers into oblivion?
I know that. That was the point.
The point was, we don't NEED a single protocol, we already have one, it's called IP.
------------------------
Jack not name, jack job!
Having read the spec, and taken a peek at the O'Reilly book, I would definitely want to use BEEP, assuming a I was writing an application that called for a new protocol. (Which I'm not, at present).
:-)
Unfortunately, for me there's still one obstacle: The lack of a perl Net::Beep module.
Yup, I'm that lazy! Until someone else(!) makes it easy in my favorite language, BEEP might as well not exist.
Anybody know of such a project in the works? My search of CPAN, Google, etc., about 6 months ago, turned up nothing.
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)
The ICAP protocol is based on the IMAP4 protocol. As such, it has the assumption of a client/server relationship. It also has state assumptions that are not necessarily valid over time, and BEEP appears to not support the concept of nested transactions (the IMAP4 and ICAP protocols are biased toward set encapsulation -- that's why there are all the irritating nested parenthesis -- which lends a strong bias toward stack based interpretation of requests: transactions).
Since BEEP is intended as a peer-to-peer connection oriented protocol, it's not ever going to really be practical as an ICAP transport.
The main issue that a server deals with is a shared resource that belongs to the system, rather than participates as a peer. This becomes an issue when you want to schedule use of a confernece room or interview office, where these resources, unlike human beings, don't have a machine which participates in the process as a peer. It's not possible to totally distribute such a system, since the peers are not the only mutually contended resources (if "Bob" drops out, then you can have a request outstanding, but not accepted; no matter who else attends your meeting, though, the conference room *must* "attend").
As far as a peer-to-peer workgroup calendaring service, it *may* be possible to use MIME encapsulated calendar update notifications, similar to the way Microsoft Outlook can be a transport for Microsoft Schedule information (the message type involved lack standardization).
However, such an approach would have the drawback of "netsplits" (in the IRC sense) redulting in shared resources ending up with conflicting scheduling (just like "operator" status in an IRC network following recovery from a "netsplit").
In general, calendaring is a much more complicated problem than people tend to give it credit for being.
Right now, the best protocol bet for Calendaring is LDAPv3 with the "persistant search" or a similar notification mechanism (e.g. LTAP), except not as a proxy, and mandatorily integrated into the LDAP server itself (due to replication requirements).
One place BEEP *might* be useful is data replication between peered servers. The primary reason it could be useful here is that the entity relationship is *peer*, not *client/server*.
-- Terry
(1) Firewalls. Port 80 wins. Resistance is futile.
(2) Semantics. HTTP's all you need.
(3) Economics. Metcalfe's Law. 1 protocol=max val.
HTTP. There can be only one.
Get your REST gear at CafePress...
Intel has released a P2P toolkit for the .NET Framework with a BEEP implementation for those interested.
e fault.a spx
It's open source and can be downloaded from:
http://www.gotdotnet.com/team/p2p/rtmp2p/d
Note BEEP is only a small part of this download - but have a look at the source code and you will see a bunch of BEEP code.
I guess we better change the name of our beep: http://www.nullsoft.com/free/nbeep/
to avoid confusion...?
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.
No.
Good to see that this protocol is as bandwidth efficient as most of the rest of the IETF protocols. Ahem.
When I read the headlines, I thought it said "Will BEER simplify network programming"? I know the answer to that one, and I can prove it over and over that BEER simplifies any kind of programming.
It's the debugging that demands sobriety....
The last time I looked at it, BEEP had nice feature of automatically relating packets being sent and forth via some sort of packet ID numbers. This automatically allowed for sessions and, what's more important, it supported asynchronious request-reply paradigm. This is very common thing one need to implement when dealing w/ more-or-less complex cli-srv architecture. Server might not only be queueing client's requests, but may also comlpete them out of the order (think of RPC, for example). BEEP provides built-in support for this behavioural pattern.
Not being a huge fan of XML, I still find BEEP initiative pretty interesting, but somewhat too generic and artificial when it comes to adopting it to real-life applications.
3.243F6A8885A308D313
Moderators: This is an example of a post that is worthy of +5 Informative. Political or religious opinions that you happen to agree with are not. They might be worth a 4, but IMHO are almost never worth a 5.
Nicely done.
I hear ya, but in practice it's the Nagle algorithm that renders TCP unusable for 80% of real-time gaming applications. There is a fine balance between free TCP 'sessionness' and the overhead of re-implementing and using sessions with custom over-UDP (or over-IP) protocol.
3.243F6A8885A308D313
JXTA, the P2P open source framework sponsored by Sun, is based on Beep. JXTA community is getting bigger and there are some very interesting projects going on (all programmed with Java, but Perl and C bindings for JXTA are in development).
Well thanks. Now I'm ticked. The ./ post made this sound very interesting taking about framing and low level down to the metal "network programming". So I followed the links. I get 5 minutes into the spec and what do I find? It's another telnet based protocol that is largely XML. I'm going to puke if I see another stupid XML networking protocol. I can't believe I'm the only one who sees how stupid it is to format all network traffic in a verbose text format like XML. Here's 448 byte "hello" example.
/>]]> />]]>
C: MSG 0 1 . 52 158
C: Content-Type: application/beep+xml
C:
C: <start number='1'>
C: <profile uri='http://iana.org/beep/TLS'>
C: <![CDATA[<ready
C: </profile>
C: </start>
C: END
S: RPY 0 1 . 110 121
S: Content-Type: application/beep+xml
S:
S: <profile uri='http://iana.org/beep/TLS'>
S: <![CDATA[<proceed
S: </profile>
S: END
BEEP is the core of the syslog over TCP (syslog-reliable, AKA RFC 3195). Since Rose was one of the authors, no surprise there.
:-)
We've been writing a new syslog daemon that supports RFC 3195 (among others) and we're just getting to the BEEP stuff.
Its not pretty, but the flexibility looks interesting. Ask us about suck-factor in about a month, we should have some opinions by then
10 print chr$(7)
See? Easy.20 goto 10
We've already got PING, now we've got BEEP. So when do we get SHOOT and EXPLODE?
If anyone knows what I'm talking about, I'll be pleasantly surprised!!!
"Information wants to be paid"
People who propose the One application protocol to beat them all often ignore existing One protocols. People love reinventing the wheel.
10 FOR g=1 TO 50
20 BEEP 0.02,g
30 NEXT g
I wrote a BEEP implementation for Perl when I was working at Enron Broadband Services, but my group was never able to get the lawyers to let give it GPL licensing and release it publically.
At the time, it seemed like our choices for letting partners have some say in network routing through our backbone were SOAP or BEEP, and we favored BEEP because of partner pressure from Sun against all things favored by Microsoft (go figure). Eventually, we used simple XML messages rather than an entire application layer.
Early on, BEEP wasn't a difficult protocol to implement; however as time passed, it grew more and more complex, until it maintaining BEEP in a closed-source environment outweighed any benefits. At that point we switched to simple XML messages.
BEEP isn't a bad protocol at all. It is a little over-designed: as a fan of eXtreme Programming, I'd have preferred that smaller versions of the protocol get wider use and more feedback before being expanded.
--binkley
Reliable-syslog, from the syslog WG in the IETF, is based on BEEP. It is fairly clever.
In reviewing reliable-syslog, I had a good look at BEEP. It is clever and neat, but XML processing _can_ be a bit heavy for many applications and there can be quite a few options in BEEP. That being said, it is still feasible. It takes quite a long while for a new 'protocol' to gain acceptence; often years.
If there is a bug in a commonly used part of beep such as the
framing code it could cause all protocols created with it to
be vulnerable.
TCP/IP and protocols running over it have had plenty of
problems in the past. From machine crashing exploits like
winnuke, boink, and teardrop to the reccent apache
vulnerability. Problems have take a long time to be found
even in widly used protocols.
I expect that people who use a medium level language instead of
creating their own protocol handling routines are unlikly to
spend time making serious effort to audit the compiler for
security problems. The BEEP project page talks about learning
previous protocol work but don't specificaly mention security
that I noticed.
<nobody> beep?
<nobody> oh this is marshall rose's latest brainchild
*** Action: nobody prepares to be outraged
<nobody> marshall rose is an ASSHOLE
<nobody> i remember the first (and last) time i met him. such an arrogant prick.
<nobody> so smug and self-congratulatory because he invented MIME
<nobody> GUESS WHAT DR. MARSHALL T. AS IN ASSHOLE ROSE? MIME SUCKS!
nobody
parturiunt montes, nascetur ridiculus mus
I see that you are talking about the Web Browser as an application, as looking at a series of HTML pages.
I suppose it all depends on your point of view. When I transfer a file via HTTP, it's just as stateless as, say, FTP.
Auto-reconnect logic, as you call it, would work just as well with HTTP as it does with FTP. It's a function of the client, not the protocol.
When XML is too much, but you still want named nested tags (easy to extend your spec) and compatibility, one option is MinXML. It's XML without attributes, cdata, comments, dtd, mixed content, etc. Just nested tags. Java and javascript parsers available. I'm messing with one in Python, not quite done yet but mostly there in two pages of code. I'm going to use it for an app where I need to apply digital signatures to something XMLish, and minXML with whitespace removed is way easier than W3C XML Signatures (40 pages for the signatures spec, plus another 40 pages for the "canonical xml" spec, plus xpath for partial signatures, plus scripting for fscks sake.)
BEEP is basically reinventing NetBIOS over TCP (rfc1001/2.txt), SMB (draft rfc from ms by paul leach) and/or dce/rpc (osf documented standard on www.opengroup.org).
BEEP doesn't have ping / echo semantics, so a client cannot establish that a server is still alive, and cannot tell the server that _it_ is still alive.
and no, maintaining the tcp connection open is _not_ a good way to say "i am still here!".
BEEP rfcs don't mention how network errors are
supposed to be handled.
BEEP doesn't describe how, if or whether the server must, or can, keep any state information such that a network error may be recovered from easily.
client / server apps are tricky to write well,
and _need_ some assistance from the transport.
Why is it that people assume that everything BEEP must be XML, it's not true. Channel 0 (the control channel) is XML, this has NOTHING to do with what an application profile's data looks like.
Profile data can be binary (and is by default) or specified by a MIME header in the frame. Other than that, it's handed off to the profile to handle, BEEP does not look inside the encapsulated data other than to pass it to the profile handler.
XML is used in the control channel, that is the limit of BEEP's imposition of XML on the world.
Sweetums
------------------------
Jack not name, jack job!
What I really can't figure out is why the first (and only) mapping document is for TCP. BEEP doesn't even buy you anything unless you can retransmit frames out of order.
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
Well said.