Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
News

Will BEEP Simplify Network Programming? 195

Posted by Cliff from the it's-a-standard-why-not-use-it dept.
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?"
This discussion has been archived. No new comments can be posted.

Will BEEP Simplify Network Programming? More

Will BEEP Simplify Network Programming?

Comments Filter:
  • Why isn't anyone adopting ... a C library called RoadRunner.

    Is a simple question mark too much to ask for?

  • I used it once... (Score:4, Funny)

    by Anonvmous Coward ( 589068 ) on Monday July 15, 2002 @08:39PM (#3890805)
    I used beep in a programming course in High School. Unfortunately, every time I used it people shouted "nosound!".

  • Agreed...BEEP is great work (Score:5, Informative)

    by robla ( 4860 ) on Monday July 15, 2002 @08:43PM (#3890843) Homepage Journal
    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 [ietf.org]). More details can be found at here [beepcore.org].

    When we were designing RTSP [rtsp.org], 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.
    • Error: 500
      Location: /beepcore/home.jsp
      Internal Servlet Error:

      java.lang.NullPointerException
      at org.apache.jasper.compiler.JspCompiler.generateNew ClassName(JspCompiler.java)
      at org.apache.jasper.compiler.JspCompiler.(JspCompile r.java)
      at org.apache.jasper.JspEngineContext.createCompiler( JspEngineContext.java)
      at org.apache.jasper.servlet.JspServlet.doLoadJSP(Jsp Servlet.java)
      at org.apache.jasper.servlet.JasperLoader.loadJSP(Jas perLoader.java)
      at org.apache.jasper.servlet.JspServlet.loadJSP(JspSe rvlet.java)
      at org.apache.jasper.servlet.JspServlet$JspServletWra pper.loadIfNecessary(JspServlet.java)
      at org.apache.jasper.servlet.JspServlet$JspServletWra pper.service(JspServlet.java)
      at org.apache.jasper.servlet.JspServlet.serviceJspFil e(JspServlet.java)
      at org.apache.jasper.servlet.JspServlet.service(JspSe rvlet.java)
      at javax.servlet.http.HttpServlet.service(HttpServlet .java)
      at org.apache.tomcat.core.ServletWrapper.doService(Se rvletWrapper.java)
      at org.apache.tomcat.core.Handler.service(Handler.jav a)
      at org.apache.tomcat.core.ServletWrapper.service(Serv letWrapper.java)
      at org.apache.tomcat.core.ContextManager.internalServ ice(ContextManager.java)
      at org.apache.tomcat.core.ContextManager.service(Cont extManager.java)
      at org.apache.tomcat.service.connector.Ajp12Connectio nHandler.processConnection(Ajp12ConnectionHandler. java)
      at org.apache.tomcat.service.TcpWorkerThread.runIt(Po olTcpEndpoint.java)
      at org.apache.tomcat.util.ThreadPool$ControlRunnable. run(ThreadPool.java)
      at java.lang.Thread.run(Thread.java)

    • Not so impressed (Score:5, Interesting)

      by Zeinfeld ( 263942 ) on Monday July 15, 2002 @10:03PM (#3891254) Homepage
      I was one of the authors of the HTTP protocol and did some work on HTTP-NG so I am broadly sympathetic to BEEP. However there are a number of reasons why it is not having a huge impact, some political, some technical.

      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.

      • Re:Not so impressed (Score:5, Informative)

        by mrose ( 205358 ) on Tuesday July 16, 2002 @03:09AM (#3892279)
        first, i'll apologize for running beepcore.org on a small server
        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... /mtr

        • Re:Not so impressed (Score:5, Interesting)

          by Zeinfeld ( 263942 ) on Tuesday July 16, 2002 @09:49AM (#3893614) Homepage
          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.)

          Ah so you are claiming that the Marshall Rose who wrote The Open Book : A Practical Perspective on Osi [amazon.com] is a different Marshall T. Rose. No sorry, Marshall you made a major technical contribution to OSI, or at least he claimed to have done so on the jacket cover of the copy I read. You did not 'kill it' at the IETF, OSI was killed in the marketplace long before 1993. The speech had the impact it did precisely because you knew the OSI stack.

          on the technical front: the beep specs use DTD not schema -- there aren't any schema fragments in either rfc3080 or rfc3081

          Well Duuuhhh read what I wrote. I checked the RFC just before posting and saw that. Schema may be 'ugly' as you put it, but none of the major XML programming platforms are based on DTDs, they are all based on schema. And BEEP is dead at Microsoft, Sun and IBM without schema, cold stone Deeeeeeaaaaadddd.

          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.)

          No, we have a five minute argument on whether to use BEEP or not, reject it and carry on.

          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.

          I wrote a fair bit of HTTP, I don't think that you have the right to go arround saying who is and who is not competent to write application protocols. If you want to get into a reputaion war you are going to loose this one. I think that BEEP is very naive when it comes to the problems that arose when it came to layering application protocols on it. I suspect that like LDAP and X500, by the time BEEP has been extended enough to be useful it will look like HTTP.

          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

          I only attended the one SACRED meeting and your comment on 'the management' is quite illustrative of the George W. Bush style crony-standards process the IETF is becomming notorious for.

          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... /mtr

          Standard old fart response 'we did it all twenty years ago sonny', 'and we did it better'. Yeah and you should have seen the anti-gravity machines we made twenty years ago.

          I don't much care for the arrogance of the IETF 'management' as you call them. I certainly don't appreciate folk who think that they have the right to make the type of off-hand blanket pronouncements on other people's work that you and they make habittually without backing it up. Your Xerox comment is absolutely typical of IETF old fartism, you want to have the right to be dismissive, you don't have the technical arguments on your side. So instead of detailing a real technical issue you allude to an earlier system, the more obscure the better. The message: 'I am too important to have to justify my comments but I believe that you are not competent to work on this problem'.

          Your comment on Web services only illustrates that you really don't understand what is going on, what people are trying to achieve or why previous efforts such as CORBA failled. I am not going to explain why or how Web Services are different because I am faaaar toooo important. I may not be old enough to have achieve old fart status but I can certainly play the part on the net.

          Still you are right on one battle, if the IETF is to regain some relevance at the upper end of the protocol stack adopting XML as the way to author RFCs is the only way forward. However the IETF is going to have to do a lot more than produce its documents in a format that does not look like utter crap from a teletype before I am going to take any standards there. I want a genuinely open and geuinely transparent process. I want standards groups to complete in 18 months, not 10 years - and yes it is possible, the SAML group I was a member of developed the basic specs which have been adopted as the basis for liberty in 18 months.

          • Ah so you are claiming that the Marshall Rose who wrote The Open Book : A Practical Perspective on Osi [amazon.com] is a different Marshall T. Rose. No sorry, Marshall you made a major technical contribution to OSI, or at least he claimed to have done so on the jacket cover of the copy I read. You did not 'kill it' at the IETF, OSI was killed in the marketplace long before 1993. The speech had the impact it did precisely because you knew the OSI stack.

            Sheesh, how on earth is knowing about OSI before publicly trashing it a crime? For people trying to make sense of the burgeoning pile of manure that was the OSI movement in 1990, MTR's books were a way to at least work out WTF OSI was on about, because it wasn't a picnic extracting this information from either: (1) the standards (unless you had a whole lotta time and masochism on your hands); or (2) the vendors (who just said "this is what you have to buy to be futureproof, shut up and buy it".)

            MTR may have attempted to inject some sanity into the OSI standards process at some stage, but given that many governments were STILL treating OSI as manifest destiny in the early 90's ("it's definitely the future, we just don't know when it's turning up in a usable form"), this could be seen as an effort make the best of a bad lot on behalf of the people who were apparently going to get it inflicted on them, failure in the marketplace or not, rather than wholehearted support for everything OSI stood for. Jump in my time machine and take a job as an IT Officer in the Australian Public Service in the early 90's, then you might see this point a bit clearer. Back then, we honestly thought we were condemned to live with this crap forever, courtesy of the Government OSI Profile (remember that?). MTR's books were very very useful for arguing with our management in an informed manner about why OSI would not actually solve our problems. And it was pretty obvious if you actually read his books that MTR was not a big cheerleader for OSI.

      • Re:Not so impressed (Score:5, Insightful)

        by Twylite ( 234238 ) <twylite&crypt,co,za> on Tuesday July 16, 2002 @03:27AM (#3892314) Homepage

        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:Not so impressed (Score:5, Informative)

          by zoydoid ( 228959 ) on Tuesday July 16, 2002 @03:59AM (#3892379)
          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.

        • 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.

          If the IESG thought that it is strange that BEEP should be allowed to progress through the process at such a breakneck pace and then have ADs going round telling others they have to give reasons why they are not using it.

          You are right about BEEP really being a transport layer protocol. Actually in the ISO model Marshall claims now to know nothing about it would be 'presentation'.

          There are several reasons why such a layer is useful, the main one being that the old farts were not as clever as they think they were. TCP has a lot of problems and you often end up wanting a protocol layer to insulate your application from them. There are all sorts of hideous things that happen if you don't close out TCP/IP sessions correctly for instance which the Berkley sockets library won't fix for you.

          The other reason people want a presentation layer is that TCP has pretty wierd performance characteristics. In the early days of the Internet you could litterally bring the system down by sending packets in faster than people could consume them. The solution to this was 'slow start' which essentially means that sessions start out at a slow speed and only ramp up the rate of packet submission as they get feedback indicating the recipient can handle it. All good stuff eh? Well yes but the parameters were set in the days of 300 baud modems and are completely inappropriate for broadband.

          What this means is that once you set up a connection you really want to keep it going. That can be problematic however since simply serializing all your requests into one channel can get real ugly when you are interleaving 32 byte instant messages onto realtime video streams.

          The way to fix a lot of these problems is to fix the TCP protocol. There is no technical reason why slow start could not be designed with memory so when you connect to CNN.com it remembers the speed it used last time. That would break the current RFC for the Internet standard but it is what a lot of vendors are actually doing on the quiet.

          What the IESG and IAB do not get is that a lot of the Internet are regarding them as damage and routing arround them. The IETF is collectively working in interupt driven mode, people propose working groups, they do stuff in response. What I do not see is a group of people stepping back and examining the internet architecture as a whole and working out ways to improve it. We just have a bunch of incremental fixes.

          In any IETF discussion the status quo is always accorded a ridiculously high status, even when it is clearly broken.

          You miss the point about SGML encoding vs SGML data model. The SGML encoding of XML is simply an artifact. If you want to apply XML at that layer in the stack you should write a better encoding.

    • I tried playing with it. For an idea whose goal is to provide a platform-neutral protocol foundation, the implementations I found seem highly unportable. None of them would even come close to compiling on OS X.

      I originally intended to dump my proprietary protocol code, but it turns out easier to maintain what I already have than to get BEEP to even function.
  • Is everybody still inventing his own application layer protocol?
    By definition, the application layer protocol is built into the application. I think you meant to say, "is everybody still foregoing the use of a presentation layer to make the application layer do less work"
    • No by definition the aplication layer protocol provides the application with access to the network stack through an API.

      Back to network design school with you! :)

      just a quick example:
      HTTP is a protocol, a web browser is a program that uses HTTP to transfer files.
      • 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...)

        • Re:Who wasn't a programmer? (Score:1, Informative)

          by Anonymous Coward
          NO!NO!NO! Application Programming Interface!
  • 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.

  • That C Library doesn't actually use BEEP (Score:5, Funny)

    by Kaz Riprock ( 590115 ) on Monday July 15, 2002 @08:48PM (#3890875)
    The guys who designed the RoadRunner C Library modified the protocol. They called it Minimal Extensible Exchange Protocol. They then implemented the protocol twice to speed up the system calls.

    This way RoadRunner goes really fast with
    MEEPMEEP!(thp-thp-thp-thpppp) this was all just a funny lie

  • 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

  • ... my game SWars [vee.net] plug, plug..

    As soon as I start working on it again, of course. If anyone wants to lend a hand, feel free.. ;)

    /mike

  • The most interesting use for BEEP that I've found so far is iCalendar's Calendar Access Protocol (CAP).
    • 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
      • ICAP was the precursor of CAP, and is not part of the iCalendar-related specification anymore.

        The newest incarnation of the iCalendar server protocol CAP is built on top of BEEP, and has an SQL-like query language that far exceeds the capabilities of ICAP.

  • My own application layer protocol (Score:4, Informative)

    by Jeremi ( 14640 ) on Monday July 15, 2002 @09:02PM (#3890954) Homepage
    "Is everybody still inventing his own application layer protocol?"

    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 [lcscanada.com] 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... ;^)

  • 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 [xmlrpc.org] or SOAP [w3c.org]) and using HTTP pipelining [mozilla.org] 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 [xatp.org] is much simpler and gets the job done just as well as BEEP.

    • If we don't need stateful connections, why are most of the protocols you mention using a stateful connection?
      • No state is maintained from one HTTP connection to the next, nor from one SMTP connection to the next.

        • to clarify (Score:1, Interesting)

          by adam_megacz ( 155700 )
          Technically, you can argue that UDP is not "connectionless", because when I send a UDP packet from my laptop, it causes it to dial up my ISP, making a PPP "connection" to the ISP.

          The idea is to introduce as little channel state (as few nested channels) as possible. BEEP is essentially "TCP over TCP".

          • so, um, does the part of the program implementing UDP communication also responsible for routing and network interface management? If that's the case, not only are you using a really funny UDP implementation you've written half an OS around it. that's probably not the most efficient way to do things.

            BEEP is NOT "TCP over TCP". Using BEEP instead of, say, sockets for implementing network application layer protocols is more like using Perl for your CGI scripts instead of C.

            My point: Do you like mucking about with character arrays and pointers and making up your own regex implementations? Do you like having to worry about packet ordering algorithms when writing, for example, a client authentication protocol? Then use a standard TCP API. But if you like being able to specify your packet length with a funcion call then ship out your data without having to mung chop slice and dice all the while worrying about buffer overflows and packet framing, use BEEP.

            It's pretty much a higher-level framework to create TCP-based application protocols. (higher-level than using the OS's standard socket API's)

            If that sounds like "TCP over TCP" maybe you think Perl is "C on C"???

            OK now that I've ranted I might add that I've never written a network application using C, nor have I designed an ALP using BEEP, so I could be full of shit. At least I read the article.

            • Hey, my karma just hit 42! So now I know the meaning of life, the universe, and everything!

              Hmm.. Perhaps that was the real question. None of this "how many roads" idiocy! :-)

          • Re:to clarify (Score:3, Informative)

            by delta407 ( 518868 )
            Technically, you are completely and flat-out wrong to argue that UDP is anything but connectionless. TCP, a connection-oriented protocol, does handshaking with the remote computer (specifically, a SYN, SYN+ACK, ACK) before anything can take place; it forms a connection. UDP, on the other hand, allows you to just blast data back and forth, reducing latency since you don't need to send three packets before sending any data. UDP does not establish a connection to the remote host, it simply allows for data exchange.

            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":
            This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism. The
            protocol is transaction oriented, and delivery and duplicate protection are not guaranteed. Applications requiring ordered reliable delivery of streams of data should use the Transmission Control Protocol (TCP).
            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.
        • Stateless is actually better at the raw protocol layer. It's a LOT easier to implement transparent failover if you don't have to worry about state issues.
        • No state is maintained from one ftp connection to the next.
          No state is maintained from one telephone call to the next.
          No state is maintained from one quake session to the next.

          By that definition, all protocols are stateless.

          • No state is maintained from one telephone call to the next.

            Then why do all these long distance calls show up on my bill to places like Texas, Tennessee, Florida, etc?

            --
            Evan

          • No state is maintained from one ftp connection to the next.

            No state is maintained from one telephone call to the next.
            No state is maintained from one quake session to the next.

            The difference with HTTP is that a user "session" (browsing your web site) encompasses multiple HTTP requests. Each request stands alone and involves a single query, single response - it's not interactive. (OK I'm simplifying, I know you can do more with HTTP 1.1.) Same with NFS - the NFS 'mount' call just sets up state in the client - the server does not maintain any state between calls. Every NFS call stands alone - the server does not even maintain open files on behalf of the client.

            Various mechanisms are used to get around the lack of server state - HTTP cookies, magic session URLs, HTTP auth. In the NFS world, the lock manager uses a separate protocol from the NFS transaction protocol - because locking must maintain state on the server - that being the whole point. (That is why "lockd" is usually a separate process from "nfsd" - RPC mechanisms such as ONC make life much easier if you stick to one daemon, one protocol.)

            By contrast, FTP, voice-over-PBX and Quake are not stateless. A single "connection" (the FTP port 21 control channel, the phone call, the Quake data channel) corresponds to the user experience of a single "session". Note that in the case of FTP at least, some clients implement "auto-reconnect" logic in case the server disconnects - this is to maintain the illusion of an unbroken session. Such is not needed with HTTP, since the server isn't maintaining a connection across user requests anyway.

            See the difference?

            • 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.
    • Pipelining my get rid of connection overhead, but it still has a fundamental limitation: The requests must be responded to in the same order that they arrived. This is a BIG problem if you have a server that handles multiple request types, some of them fast, some of them slow. If you get a slow request followed by a dozen fast requests, those fast requests will have to wait until you can generate an answer for the slow request, since you MUST send the answer for the slow request first.

      This is the main reason why I implement my own protocol instead of just use HTTP. Supposedly BEEP can handle this case, but the code doesn't seem to compile, so I haven't tried it out.
      • Hmm. It sure used to.

        Yes, BEEP handles the case you talk about, but only if you have opened multiple channels within the connection. Each channel is processed synchronously, there is no guarante of synchronous or ordered processing between channels. This is not to say that the channel handlers can not impose this within the application, but the protocol itself does not.

        Sweetums
    • 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)
      • Why can't we all just use IP the way it was meant to be used?

        According to the beepcore FAQ, it's because of NAT and server pooling - you're not guaranteed that multiple requests for connections between two machines actually will be between the same two machines.

        As you mentioned, IPv6 would have prevented the problem. It's just a decade too late.
  • Comment removed based on user account deletion

  • well (Score:3, Insightful)

    by mindstrm ( 20013 ) on Monday July 15, 2002 @09:14PM (#3891024)
    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.
    • There is a REASON that the Internet is based on IP

      Amen Brother!

      I should point out for those that might've missed your point that TCP, UDP, and GRE are all "session" layer protocols, which are lower level than application, but still we don't have *just one* of them. So why should there be *just one* application layer?

      What's missing from this conversation is the presentation layer. IMHO, this is what XML is all about. Of course, what I think is really missing in industry is a new layer between presentation and application that all of us can ignore as we begin to focus on the presentation layer...

  • Definitely not new, but... (Score:3, Informative)

    by Nick Arnett ( 39349 ) on Monday July 15, 2002 @09:14PM (#3891028) Homepage
    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.

  • XML is too much sometimes (Score:4, Insightful)

    by Pauly ( 382 ) on Monday July 15, 2002 @09:24PM (#3891090)
    I've played with BXXP/BEEP [bxxp.org], 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 [jabber.org]. 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 [elibel.tm.fr] and RPC [opengroup.org] 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 [cr.yp.to] to suit my admittedly low-level needs better. Sadly, as XML and its derivatives mushroom in complexity, I find them less appealing.

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

      Only Bernstein could think that an ASCII representation of Pascal strings is original.
      • Of course, Pascal strings have a fixed maximum length, and netstrings don't. And they don't just handle ASCII, any type of data can be stuffed into them. Including, recursively, other 'netstrings'.

        Anyway, I didn't see anything on that page stating that this would change the world. The "original" part is coming up with a simple way to encode them that's trivial to parse, can be recursively embedded, and has minimal overhead with some chance for error-checking.

        It it earth-shattering? No, but it's clever.

        • OK, so you have the length of the string up front. And the length is encoded in ASCII, so it's theoretically unlimited. But how much space do you allocate for the length? How many bytes can it be?

          It seems much simpler to assume that a 4-byte binary length will be sufficient. I haven't had to deal with strings longer than 2^32 recently. If you DO have strings that large, your ASCII-encoded length is going to be 10 bytes long.

          If you want to include error checking, put a 4-byte CRC/checksum/adler32 after the length.
  • 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.
  • 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."

    List:
    http://lists.codefactory.se/pipermail/roadrunner/2 002-July/thread.html [codefactory.se]

    (codefactory is the company working on GtkHTML and Mr. Project, btw).

  • REST, Jabber, SOAP (Score:2, Interesting)

    by tburke ( 29991 )
    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.

  • Beep? (Score:2, Funny)

    by skaffen42 ( 579313 )
    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...
    • The Beeb was wonderful - I wish I still had mine.

      It offered a programming environment which allowed for 6502 assember embedded in interpreted BASIC. How deliciously perverse!

    • GOTOs Represent! (Score:1, Insightful)

      by 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)
  • Internal Server Error

    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?

  • i believe part of the EPP draft deals w/ using BEEP as a communication layer.

    the .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".
    • Here's a link to the draft describing EPP transport using BEEP:

      http://www.ietf.org/internet-drafts/draft-ietf-p ro vreg-epp-beep-02.txt

      As one of the folks involved in the EPP/BEEP discussions, I can confirm that most of the concerns had to do not only with a lack of experience with current BEEP implementations, but a wealth of experience with streaming data over TCP. Implementers just felt more comfortable working with tried and true technology. It will be nice, though, if we get a chance to implement this draft and see if any of the early performance and complexity concerns were justified.
  • I know for a fact that the server is not very brawny. Here's a note from beepcore.org.
    WE'VE BEEN SLASHDOTTED... sorry! Because the beepcore.org server is built using apache/tomcat, but runs on a small server, it can't handle the load of the slashdot hordes. So, you're getting this statically-generated page instead.

    If you really want to get to the dynamic site, click on the logo above.

  • 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 guess we better change the name of our beep: http://www.nullsoft.com/free/nbeep/

    to avoid confusion...?

  • The BEEP community is strong and gettng stronger (Score:3, Informative)

    by jrimmer ( 70379 ) <jrimmer @ i rth.net> on Tuesday July 16, 2002 @12:05AM (#3891750)

    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:
    • BEEPCore-Java [sourceforge.net] - Java implementation with a BSD-like license
    • BEEPCore-C [sourceforge.net] - C/C++ implementation with a BSD-like license
    • PermaBEEP [permabit.com] - C implementation with a SleepCat-like license
    • BEEP4j [beep4j.org] with an Apache-like license
    • PyBeep [sourceforge.net] for Python with an unknown, but OSI approved, license
    • RoadRunner [codefactory.se] - C and Python implementation with an OSI approved license.
    • Beepcore-Ruby [sourceforge.net] - Ruby implementation (though just beginning) with a BSD-like license

    There's an excellent IRC channel at OpenProjects [openprojects.org] with the kitschy name #beepnik.

    There's the obligatory O'Reilly book, BEEP: The Definitive Guide [oreilly.com].

    But the best source for information is the Beepcore.org [beepcore.org] site which has, among other things, an excellent whitepaper [beepcore.org] on the justification and design of the BEEP protocol.

    • 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.
  • 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....

  • Annoyed (Score:5, Interesting)

    by KidSock ( 150684 ) on Tuesday July 16, 2002 @03:17AM (#3892297)
    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

    • Re:Annoyed (Score:4, Insightful)

      by anshil ( 302405 ) on Tuesday July 16, 2002 @06:01AM (#3892592) Homepage
      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.

      • In example what does XML-RPC do any good? Is conventional RPC suddendly uncool? What can XML-RPC do, what normal RPC can't?

        Drive the market for massively high bandwidth, Gigabit switches, Pentium 4s and horribly expensive application level firewalls...?

      • Also annoyed and hating XML. Okay, XPATH searching is admittedly extremely cool. But how many apps really need this and use it? More marketspeak, less speed, yecch.

        The main two things I've seen about XML are:
        1. It makes medium-speed platforms like tomcat very, very slow performers.
        2. It is hard to explain to users, who need to understand arcane concepts in order to exploit it.
        3. The simple uses of it are indistinguishable from what can be done with config files.
        4. When it really starts getting used you start seeing network competition effects like browser wars, differences in embedded languages, and rendering artificats.
        5. It is relatively easy to bullshit vaporware, bloatware, and rapacious software houses if it has an XML in it (or an "e-commerce", a "secure key", or a "content management").
        6. That said, it can be a great tool. But I don't want to eat, sleep, and breathe the stuff!

      • Re:Annoyed (Score:3, Insightful)

        by ceswiedler ( 165311 )
        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.
      • 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.

        How about that you CAN telnet to the relevent port and type the right data. Text based protocols like SMTP, POP, HTTP, etc are very easy to write clients for, and to debug, because you can simply write & read text. Binary based protocols like DNS require special libraries or more complex programming.

  • 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!!!

Slashdot Top Deals

"What man has done, man can aspire to do." -- Jerry Pournelle, about space flight

Close