Q. Is BEEP a replacement for HTTP? Will I have to start writing beep:// everywhere?
A. No. BEEP is a framework for building application protocols. It's not a replacement for any existing protocol. Instead, it's kind of a "best hits" album of the tricks used by experienced application protocol designers since the early 80's.
If you attend many working groups in the IETF, you'll notice that whenever they get together to define a new application protocol, most of the time is spent arguing the same issues, over and over and over again. Although the goals and needs of application protocols may differ quite a bit, there's a lot of application protocols that pretty much have the same set of design requirements.
This is what BEEP is for. Someone sat down, did an inventory of what techniques got used a lot, what the tradeoffs were, made some choices, and then integrated it all together.
Although some might make passionate arguments for a particular approach, at the end of the day you just have to pick something and make it work. Hopefully with BEEP, the people designing application protocols will start arguing about other things. If we're lucky, those things will be a lot more important.
If you'd like more details, check this out.
Q. Do you have an example of a protocol defined using the BEEP "framework"?
A. Sure!, check this section to more about RFC defined on top of BEEP protocol.
Q. Why was BEEP first called BXXP?
A. At the time, the letter "X" was pretty much de rigueur in any new technology. However, "X" isn't the first letter in "Extensible" and "Exchange," and further, BEEP has much more comic potential. So the IETF working group on BXXP renamed it BEEP.
Q. Is BEEP slow because it uses XML?
A. BEEP uses XML to start things called "channels" when you establish a session. A channel is something that carries your data. The use of XML inside BEEP is located (and isolated) at channel management definition which is a common part to all BEEP enabled peers. XML is not used, or enforced to be used at any other part!
You can actually use a binary encapsulation format to transfer your data on top of channels, if you don't like XML. The way BEEP is extended to perform the application specific task is through the definition of an agreement between peers called profiles.
A BEEP profile is something that the application protocol designer defines. A profile describes the syntax and semantics of the data exchanged over a BEEP channel.
So, the choice of XML is pretty much up to the protocol designer. If you want your data to be encoded using XML, that's up to you. If you want your data to be encoded using something else, such as a compact binary representation, that's OK too. So, BEEP's use of XML can be limited to a couple of handshakes at the beginning of your session.
As to whether XML is slow, well, your mileage may vary.
Q. Does BEEP use XML for framing?
A. No, an octet-counting mechanism similar to the one used by HTTP is used.
XML isn't a universally acceptable choice as a framing protocol. There are two reasons for this:
- XML isn't suited towards carrying arbitrary binary objects; and,
- If you have an error in the nested XML content, you're pretty much screwed trying to find where the frame ends.
XML is good for many, many things, but raw octet framing isn't one of them.
Q. Isn't there an added layer of abstraction? Doesn't this extra layer make things slower?
A. Yes it does! However, when people get down to write new program languages, abstraction layers and many other programing abstraction techniques they are seeking:
- To be productive: abstraction is good because human
beings are more efficient thinking in abstract terms
rather than handling the detail. This explains why many high level
languages have been written such as Java, and why people prefer
to use them rather than assembler language.
Producing application protocols in a higher level manner allows to prototype faster, share knowledge/code between several applications, and many more good benefits...
- To produce maintainable products: Axiom: the higher level your product is, the more maintainable it gets. However, as a side effect your product gets reasonably inefficient.
- To be scalable: BEEP provides a way to keep on building new applications protocols on top of it as new data encapsulation format appears, new network application protocols are needed, just reusing the same piece of code/RFC.
- To be reusable: Well, BEEP is mainly targeted on reusing network features/mechanism that are integrated in a coherent network framework definition that many applications could reuse!
Q. I understand previous question but, how this slowdown/inefficiency applies BEEP?
Let's analyse each point that could make the protocol to be inefficient.
There is a framing protocol, which some very simple application protocols can do without. The framing protocol adds about 60 octets per exchange, and is designed to be simple to parse (i.e., very fast to parse).
There is a handshake at the beginning of a session, which any protocol that's going to allow for feature negotiation (e.g., picking a security mechanism) is going to have anyway.
There is a handshake that happens when you start a channel, but you can piggyback your first request and response in the handshake.
Other other features that BEEP has, such as authentication, privacy, error codes, and so on, are things that "adult" application protocols have anyway.
The key thing to appreciate is that minimal BEEP is very close to a very simple application protocol, as you ask for more features BEEP will give you those using the "best practices" of some earlier protocols.
Q. What's the relationship between BEEP and HTTP-NG?
A. There isn't any. HTTP-NG was an effort a few years ago to develop a next generation HTTP to make Web interactions more efficient.
There is some overlap because HTTP is a TCP-based application protocol with many, though not all, of the requirements that BEEP tries to address (e.g., multiplexing).
There is also a lot of disjoint space between the two, most acutely because HTTP-NG was (rightly) an HTTP-centric project and BEEP has a different focus. To name one example, HTTP follows a client-server model, but BEEP is peer-to-peer.
Q. Is BEEP available for C, C++, Java, Tcl, and so on?
A. Yes. BEEP is available for C, C++, Java, and Tcl. Take a look here for various BEEP-related projects.
There used to be a BXXP implementation written for early version of Apache 2. we're waiting for Apache 2 to stabilise a little more before we write a BEEP implementation. For the record, a BEEP module for Apache 2 would be a very cool thing.
Q. What's the point of multiplexing different data streams over a single TCP connection? Why not just open up multiple TCP connections if you want to multiplex? Why not let TCP do the hard work?
A. We'll answer these in reverse.
Actually, BEEP does let TCP do the hard work. BEEP usually sits on top of TCP (like most connection-oriented application protocols). See this for the details.
On the surface, using multiple TCP connections for multiplexing synchronised data streams is a good idea. In practice, there are no deployed application protocols that do this.
Although FTP uses two TCP connections (one for control and one for data), its operational robustness has been severely compromised due to the deployment of NATs (and other network bugs).
Some sites deploy load-balancing devices that transparently rewrite IP addresses among servers. What this means is that if you open up two TCP connections to the same IP address, it's anyone's guess as to whether they actually terminate at the same physical machine.
Purists scoff that this violates the end-to-end principles of the Internet architecture, but people keep deploying them anyway.
You could argue that HTTP does this successfully, and you'd be half-right. Browsers that use HTTP often open up multiple connections to the same servers, but from the server perspective each connection is coming from an independent entity, and the server still has to do all the authorization stuff on each connection.
Also, until ensemble TCP is deployed, the multiple connection thing isn't very network friendly either: multiple connections to the same host don't share any learning between them so you get a latency hit when the connection is established (slow start).
However, the reason BEEP does multiplexing is because many application protocols can make good use of parallelism. BEEP tries to figure out how to do this in a way which is less network- and server- intensive.
BEEP is designed to be run over protocols other than TCP. For example, there's a new transport protocol coming out of the IETF oven called SCTP that has TCP-like properties (reliability) but also supports multiplexing data streams. This is a natural fit for something like BEEP.
Q. But doesn't this multiplexing make it harder to administer or block traffic?
A. Quite the reverse. For a single BEEP session, you have a single user-identity. What this means is that you can authenticate when you establish the BEEP session and keep that identity for all the channels riding on the session.
Q. What's the difference between BEEP and Beepcore?
Q. I don't clear understand what is a profile and how it relates to BEEP.
BEEP is a protocol to write new application protocols. This means that you can't use BEEP directly to send and receive data, if you don't extend BEEP to implement your specific application protocol.
This is done by extending BEEP, adding your application protocol on top of it. The way BEEP is extended, to fulfill your protocol requirements, are: profiles.
From a conceptual point of view, without taking into account how each BEEP toolkit implements the profile concept, we could say that a profile is just an agreement between BEEP peers that they implement some application protocol, identified by the profile, which involves to know how to process messages to be exchanged by the profile and their meaning.
Another concept to consider is that BEEP channels are created under the semantic of a profile. In other words, if you define your profile "A" and a profile "B", which are different application protocols, you are allowed to create channels that are bound to run under the profile "A" or "B".
Now, once the profile, that define your application protocol, is defined, you need to implement it following indications of the BEEP toolkit you are using.
Q. Does BEEP smell like Java? Isn't all this extensibility a problem in the making?
A. BEEP is language-independent. This enables Beepcore to
be an implementation of BEEP written in C, Perl, Tcl, Java, etc.
Just like cholesterol, there's good and bad extensibility. The kind of extensibility you find in BEEP is hopefully the good kind. What BEEP does is provide very well-defined hooks as to how it can be extended. You can also read "well-defined" as "limited" if you like.
Q. What's the difference between Napster/Gnutella/... and BEEP?
A. Napster and Gnutella are open source applications that use flooding algorithms to widely distribute information.
BEEP is a framework for writing application protocols that may, or may not, use flooding algorithms.
It would be pretty cool to have an information distribution protocol be defined using BEEP. We know just the guy who'd like to do it... We'd like to tell you who, but we wouldn't want to get a nasty letter from the RIAA's attorneys.
Q. Is BEEP as secure as existing protocols?
A. There are secure protocols out there? Why weren't we informed? Just kidding.
Security in BEEP is achieved, at the core, through the use of SASL and TLS.
With SASL, you can pick your level of assurance, e.g., one-time passwords, public key signatures, and so on.
However, this by itself doesn't amount to much. To answer your question, you need to look at how the application is provisioned. For example, in the reliable syslog specification, there's a section devoted to security threats and how you can counter them (or not) using BEEP.
Q. What's difference between SOAP and BEEP?
A. Briefly, SOAP = XML + RPC + HTTP. Less briefly, SOAP is an RPC mechanism that uses XML for encoding and prefers HTTP for transport.
BEEP is a framework for writing application protocols that are message-oriented, which may, or may not, use XML.
RPC-based applications tend to be tightly coupled; message-oriented applications tend to be loosely coupled. There's a spectrum there, but the edges are pretty sharp, c.f., Section 2 of this.
However, the real question to ask is whether it makes sense to define a BEEP profile that does SOAP. Outside of the increase in performance and reliability, you probably wouldn't notice the difference.
Q. Can you use Telnet to talk to a BEEP server?
A. Yes, it's a little tricky though, since you need to be able to count octets...