Building port oriented applications and BEEP

Network application protocols state of the art

All currently deployed application protocol such SMTP, HTTP, FTP, etc runs on a particular port making it more easy for developers and users to take advantage of the resource provided, because many settings are assumed.

In the past this approach was really helpful because many network design problems were solved for free: session setup, protocol identification, versioning, security level,..

For example, if it is required to "talk" plain HTTP you can use the default TCP port 80 to reach the web server at a particular location. However, if you want to secure your session you must use a different port, that is 443, because "by contract" the application protocol bind to the 80 port runs the HTTP without secure the session.

The same happens with many application protocols that must be secured, or "tuned", to provide a particular feature plus the application protocol that provides the resource required.

As everything, this has advantages: easy deployment, protocol location (many site administrators block applications not by content but by port), etc, but it also has drawbacks.

Taking a look into limits imposed by port driven application protocols

All features that provides "for free" a port driven approach are at the same time flaws in the long term. Taking separately we can see how they have a deep impact in our design. Understanding them its the first step to make a proper choice while designing network application protocols.

  1. No or minimal protocol negotiation phase:

    Assuming you are going to find a particular application protocol at a particular port (i.e, SMTP on 25 TCP port) you can skip all details that could require peer connection, identify your credentials and then ask for your protocol.

    However, if the protocol requires to be mixed or extended with some feature that falls outside the protocol scope or capability it is now required to talk to "a new" version of the protocol in a different port. Obviously this is far from being desired but happens specially with protocols that are previous to the SSL/TLS appearance.

    In this case, the port driven approach uses a new port. In the case of BEEP a new BEEP profile is provided, making it to be available at the same port, making old and new client applications to coexist.

  2. Port bound protocol:

    Until now, a common idiom is to assume the port according to the protocol being used and viceversa. Though it is argued that it makes more easy software development and makes life easy to end users, some experience shows that it is required to be able to move services to different ports.

    However, in many cases this is not possible because, again, the application protocol design. So, why design an application protocol that is "married" with a particular port?

    The answer was two fold: first, there was nothing like BEEP that could help two different application protocols to coexist at the same TCP port, making difficult to move applications to different ports. Second, it is supposed it is easy for client applications to reach the server side application assuming the TCP port.

    While the first answer is pretty clear, the second is not so accurate now having BEEP. A really flexible approach would be to have a "default port" where the application server is usually reached but, it should be possible to place the server application at a different one.

    It is difficult to understand that, in many cases, current client Internet applications doesn't provide a TCP port configuration to reach the server application because "it is too much setting for the end user!!".

  3. Being one step ahead to the change

    Many experienced network application designers take into account that features not envisioned by its protocols will happen. Several measures are provided, but the most common is versioning the protocol. However, this do not solve all problems as showed with the TLS/SSL case.

    BEEP provides a flexible and powerful mechanism to perform a session setup, allowing to mix and extend your protocol (a BEEP profile) with several existing BEEP profiles.

    This is great not only because the amount of work already done, but because it is a warranty that the change that will happen will be covered easily by new BEEP profiles, making your protocol to be fresh and up to date.

    For example, the Af-Arch platform [1] provides its RPC services through two profiles at the same time. This allows client applications to use the "Coyote" or the "XML-RPC over BEEP" profile to invoke services.

    This is done because initially the Coyote profile was defined to perform a XML-RPC invocation without too much features (really limited protocol) but simple enough for the kind of services exposed by Af-Arch servers. With the time Shaper [2] was written and a XML-RPC invocation profile with support for data typing was required.

    Obviously rewriting the "Coyote profile" was not a reasonable option. Having BEEP allowed to support over the same connection "Coyote" and "XML-RPC over BEEP" which fitted really well due to its data typing support.


The very first concept to change while building applications with BEEP is to not think about running a particular BEEP profile at a particular port. This is because BEEP is able to run any configuration at any port due to its design.

A little experience with BEEP and its building block reuse pattern shows that several BEEP profiles are used and combined to produce the "useful work" at the same port (without being important this last detail).

For example, you can run a mixture of XML-RPC over BEEP, SASL and TLS, with a custom profile to provide some service. In this case, you can use the IANA port assigned to the XML-RPC over BEEP, 602 TCP port, but once connected you are in fact running several protocols on port 602.

What happens is that your client application reached the 602 TCP port, negotiated a TLS tuning to secure your connection, then provided SASL credentials, and then asked to use the XML-RPC over BEEP profile. But, at this last step, your client application could have asked for other BEEP profile.

It is recommended to design BEEP applications to use as "default port" anyone provided for current IANA BEEP accepted profiles, but at the same time, allowing to move that application to any port. The same applies to new BEEP profiles with IANA assigned ports. These ports should be taken only as "default" values.

Some of IANA assigned ports to BEEP profiles are:

  1. 601 TCP: RFC3195 Reliable Delivery for syslog
  2. 602 TCP: RFC3529 XML-RPC over BEEP
  3. 604 TCP: RFC3620 The TUNNEL profile


  1. [1] Af-Arch framework
  2. [2] Shaper: creating xml documents from XML-RPC over BEEP servers