General questions

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.

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!

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.

And beepcore could be the BEEP Core community site or
several related projects that have used that name to identify its
projects. Some of them are: beepcore-c, beepcore-java or beepcore-tcl.

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.

TLS
is the IETF's redition of SSL version 3. For a good overview of
security design for application protocols, take a look at this.

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.

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