2. Examples
While the semantics described in Section 4 may seem complex, the
results are actually relatively simple. A few examples will show the
operation and use of this profile. In these examples, the machine
attempting to establish the connection is named "initial", while the
intermediate proxies are "proxy1" or "proxy2", and the machine with
the service that "initial" wishes to access is called "final". The
examples also assume that the BEEP framework [2] is implemented on
top of TCP [3], or some other mapping where one transport connection
carries all channels.
2.1. One-Hop Example
A simple one-hop connection through a single proxy is illustrated
first.
initial proxy1 final
----- xport connect ----->
<------- greeting -------->
--- start TUNNEL [1] ---->
----- xport connect ------>
<-------- greeting -------->
---- start TUNNEL [2] ---->
<---------- ok ------------
<------- ok -------------- [3]
<------------- greeting [4]-------------------------->
Notes:
[1] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='604'>
<tunnel/>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel/>
[3] At this point, immediately after sending the <ok/> element,
proxy1 starts passing octets transparently. It continues to do
so until either transport connection is closed, after which it
closes the other.
[4] This greeting may include the TLS profile, allowing initial and
final to communicate without proxy1 understanding or interfering
without being caught.
2.2. Two-Hop Example
The second example shows the initiator connecting to its proxy, that
proxy connecting to another, and finally that second proxy finding a
service outside.
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' port='10290'>
<tunnel/>
</tunnel>
[3] The TUNNEL element looks like this:
<tunnel/>
[4] Proxy2 starts passing octets transparently after sending the
<ok/>.
[5] Proxy1 starts passing octets transparently after sending the
<ok/>.
2.3. Failed Set-Up Example
The third example shows the initiator connecting through two proxys,
the second proxy attempting to connect to the specified service and
finding the destination is not a BEEP server. (Of course, specifying
the telnet service can be expected to lead to this error.) The same
would result if the destination did not support the TUNNEL profile.
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
----- xport close ---->
<---- <error> -------
--- xport close ---->
<---- <error> ------
--- xport close ---> [3]
Notes:
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
</tunnel>
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
<tunnel/>
</tunnel>
[3] This close is optional. "Initial" may also send another <tunnel>
element, attempting to contact a different server, for example.
2.4. Non-BEEP Example
This example shows the initiator connecting through two proxys, the
second proxy attempting to connect to the specified service and
accepting that the destination is not a BEEP server. The difference
at the protocol level is two-fold: The "initial" machine does not
include the innermost "tunnel" element, and the final proxy
("proxy2") therefore does not expect a BEEP greeting.
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
--- xport connect -->
<----- greeting ----->
--start TUNNEL [2]-->
---- xport connect --->
<------- login: -------
<------ <ok> ------- [3]
<----- login: ------ [4]
<------ <ok> --------- [3]
<----- login: -------- [4] [5]
Notes:
[1] The TUNNEL element looks like this:
<tunnel fqdn='proxy2.example.com' port='604'>
<tunnel fqdn='final.example.com' svc='_telnet._tcp'>
</tunnel>
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element.
[2] The TUNNEL element looks like this:
<tunnel fqdn='final.example.com' srv='_telnet._tcp'>
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element.
[3] Each proxy starts transparently forwarding octets after this
<ok>.
[4] Each proxy forwards any data it received from the final host,
even if that data arrived before the <ok> was sent.
[5] After receiving the "ok" message, the "initial" peer can expect
raw, non-BEEP data to be sent to and received from the "final"
machine.
This example shows the initiator connecting through two proxys. The
initial machine knows there is a server offering the SEP2 profile
somewhere beyond proxy1, but it need not know where. Proxy1 has been
locally configured to know that all SEP2 servers are beyond proxy2.
Proxy2 has been locally configured to chose "final" as the server of
choice for SEP2 services. Note that "final" does not necessarily
need to offer the requested profile in its initial greeting.
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
[1] The TUNNEL element looks like this:
<tunnel profile="http://xml.resource/org/profiles/SEP2"/>
Note the lack of an innermost no-attribute <tunnel> element.
[2] Proxy1 maps this to
<tunnel fqdn="proxy2.example.com" port="604">
<tunnel profile="http://xml.resource/org/profiles/SEP2"/>
</tunnel>
based on local configuration, then processes the new
element, stripping off the outer element and routing
<tunnel profile="http://xml.resource/org/profiles/SEP2"/>
to proxy2.
[3] Proxy2 receives the TUNNEL element with simply the SEP2
URI specified. Local provisioning maps this to
<tunnel fqdn='final.example.com' srv='_beep._tcp'>
<tunnel/>
</tunnel>
Note the presence of an innermost no-attribute <tunnel> element.
Proxy2 then strips the outermost element, looking up the
appropriate address and port, and forwards the <tunnel/>
element to the final machine.
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[5] Proxy1 starts transparently forwarding octets after this <ok>.
This example shows the initiator connecting through two proxys. The
initial machine knows there is a server known as "operator console"
somewhere beyond proxy1, but it needs not know where. Proxy1 has
been locally configured to know that "operator console" is beyond
proxy2. Proxy2 has been locally configured to use "final" as
"operator console". This example is almost identical to the previous
example, except that "endpoint" is intended to route to a particular
server, while "profile" is intended to route to a particular service.
Otherwise, these two attributes are very similar.
initial proxy1 proxy2 final
--- xport connect -->
<---- greeting ------>
--start TUNNEL [1]-->
-- xport connect --->
<----- greeting ----->
--start TUNNEL [2]-->
--- xport connect --->
<------- greeting ----->
---start TUNNEL [3]--->
<-------- ok ----------
<------- ok --------- [4]
<------- ok --------- [5]
<-------------------------- greeting ---------------------------->
Notes:
[1] The TUNNEL element looks like this:
<tunnel endpoint="operator console">
</tunnel>
Note the lack of an innermost no-attribute <tunnel> element.
[2] Proxy1 maps this to
<tunnel fqdn="proxy2.example.com" port="604">
<tunnel endpoint="operator console">
</tunnel>
</tunnel>
based on local configuration, then processes the new
element, stripping off the outer element and routing
<tunnel endpoint="operator console">
</tunnel>
to proxy2.
[3] Proxy2 receives the TUNNEL element with simply the endpoint
specified. Local provisioning maps this to
<tunnel fqdn='final.example.com' srv='_beep._tcp'>
<tunnel/>
</tunnel>
Note the presence of an innermost no-attribute <tunnel> element.
Proxy2 then strips the outermost element, looking up the
appropriate address and port, and forwards the <tunnel/>
element to the final machine.
[4] Proxy2 starts transparently forwarding octets after this <ok>.
[5] Proxy1 starts transparently forwarding octets after this <ok>.
