In BEEP, as soon as a session is started, both peers send a greeting. But how can a greeting be sent if there aren’t any channels to send it on?
The answer is that a newly-created BEEP session always comes with one channel, channel zero, already created. Channel zero’s sole role is channel management, which means three things:
Creating new channels
Destroying existing channels
Releasing the entire session
These are shown in Figure 3-3; let’s look at each in turn.
Figure 3-3. The channel zero precept
Earlier, in the section Channels in Chapter 2, we talked about BEEP’s “suggest many, accept one” philosophy and how this was used, among other things, for channel creation.
To recap, after they exchange greetings, when one peer wants to open a channel it might suggest:
<start number='1'> <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> <profile uri='http://iana.org/beep/SASL/OTP' /> </start>
and, if the other peer decides to start channel number 1, it will indicate which of these two profiles it selected.
It turns out that there were two nuances that we left out earlier:
Piggybacking initial data
Requesting a “virtual host”
BEEP provides a latency-reduction mechanism that lets you create a channel and perform its first exchange at the same time.
The basic idea is to remove one round-trip time from the process. Instead of having to wait a round-trip ...