📄 x3837.htm
字号:
<HTML
><HEAD
><TITLE
>XML Streams</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.64
"><LINK
REL="HOME"
TITLE="Programming Jabber"
HREF="book1.htm"><LINK
REL="UP"
TITLE="Jabber Technology Basics"
HREF="c3612.htm"><LINK
REL="PREVIOUS"
TITLE="Resources and Priority"
HREF="x3795.htm"><LINK
REL="NEXT"
TITLE="The Jabber Building Blocks"
HREF="x4089.htm"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Programming Jabber</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="x3795.htm"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
>Chapter 5. Jabber Technology Basics</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="x4089.htm"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="JABTDG-CH-5-SECT-5.3"
>XML Streams</A
></H1
><P
>By now, you should already know that Jabber relies heavily on XML.
XML courses through Jabber's veins; data sent and received between entities,
and internally within the server itself, is formatted in XML <I
CLASS="EMPHASIS"
>packets</I
>.</P
><P
>However, the XML philosophy goes further than this.
A connection between two Jabber endpoints, say, a client and a server, is
made via a TCP socket, and XML is transferred between these endpoints.
However, it's not just random fragments of XML flowing back and forth.
There is a structure, a choreography, imposed upon that flow.
The entire conversation that takes place between these two endpoints
is embodied in a pair of XML documents.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5-SECT-5.3.1"
>The Conversation as XML Documents</A
></H2
><P
>The conversation is two-way, duplexed across a socket connection. One one
side, the client sends an XML document to the server. On the other side,
the server responds by sending an XML document to the client.
<A
HREF="x3837.htm#JABTDG-CH-5-FIG-XMLSTREAMS"
>Figure 5-3</A
> shows the pair of XML
documents being streamed across the TCP socket connection between
client and server, over time.</P
><DIV
CLASS="FIGURE"
><A
NAME="JABTDG-CH-5-FIG-XMLSTREAMS"
></A
><P
><B
>Figure 5-3. Client<->Server conversation as a pair of streamed XML documents</B
></P
><PRE
CLASS="SCREEN"
> +--------+ +--------+
| | | |
| | TCP socket | |
| |=========////==================================| |
| | client sends XML document to server ---> | |
| |---------////----------------------------------| |
| |</root>..////...<child2/>..<child1/>..<root> ->| |
| |---------////-----------------------------doc1-| |
| client | | server |
| |---------------------------------////----------| |
| |<- <root>..<child1/>..<child2/>..////...</root>| |
| |-doc2----------------------------////----------| |
| | <--- server sends XML document to client | |
| |=================================////==========| |
| | | |
| | | |
+--------+ +--------+
Key:
=====================
TCP socket connection
=====================
//// - gap in time
---------------------
streamed XML document
--------------------- </PRE
></DIV
><P
>But what do we mean when we say that the conversation is an XML document?
To answer this, consider this simple XML document:</P
><P
><PRE
CLASS="SCREEN"
><?xml version="1.0"?>
<roottag>
<fragment1/>
<fragment2/>
<fragment3/>
...
<fragmentN/>
</roottag></PRE
></P
><P
>The document starts with a document type declaration:</P
><P
><PRE
CLASS="SCREEN"
><?xml version="1.0"?></PRE
></P
><P
>which is immediately followed by the opening root tag. This root tag is
significant because there can be only one (and, of course, its corresponding closing tag)
in the whole document. In effect, it wraps and contextualizes the content of the document.</P
><P
><PRE
CLASS="SCREEN"
><roottag>
...
</roottag></PRE
></P
><P
>The real content of the document is made up of the XML fragments that
come after the opening root tag:</P
><P
><PRE
CLASS="SCREEN"
><fragment1/>
<fragment2/>
<fragment3/>
...
<fragmentN/></PRE
></P
><P
>So, taking a connection between a Jabber client and a Jabber server as
an example, this is exactly what we have. The server is listening on
port 5222 for incoming client-initiated connections.
Once a client has successfully
connected to the Jabber server, it sends an XML document
type declaration and the opening root tag to announce its intentions to
the server, which in turn responds by sending an XML document type declaration and opening
root tag of its own.</P
><P
>From then on, every subsequent piece of
data that the client sends to the server over the lifetime of the connection
is an XML fragment
(<TT
CLASS="LITERAL"
><fragmentN/></TT
>). The connection
can be closed by the client by sending the matching closing root tag. Of course, the connection can be also
closed by the server by sending the closing root tag of
<I
CLASS="EMPHASIS"
>its</I
> XML document.</P
><P
>The fragments sent within the body of the XML document are the XML building blocks on which Jabber solutions are based.
These XML building blocks are introduced and examined in the next section.</P
><P
>Suffice it to say here
that these fragments can come in any order within the body of the XML
document, precisely because they're <I
CLASS="EMPHASIS"
>in</I
> the body. As
long as an XML document has a root tag, and the fragments themselves are
well-defined, then it doesn't matter <I
CLASS="EMPHASIS"
>what</I
> the content
is. Because of the way the document is parsed—in chunks, as it
appears—it doesn't matter if the fragments appear over a long period,
which is the case in a client/server connection where messages and data
are passed back and forth over time.</P
><P
>It should be fairly easy now to guess why this section (and
the technique) is called “XML Streams”. XML is <I
CLASS="EMPHASIS"
>streamed</I
>
over a connection in the form of a document, and is parsed and acted upon
by the recipient in fragments, as they appear.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="JABTDG-CH-5-SECT-5.3.2"
>The Opening Tag</A
></H2
><P
>Earlier, we said that the opening document tag was used by the client to “announce
its intentions.” The following is a typical
opening document tag from a Jabber client which has made a socket connection
to port 5222 on the Jabber server <TT
CLASS="LITERAL"
>jabber.org</TT
>.</P
><P
><PRE
CLASS="SCREEN"
><stream:stream
xmlns:stream="http://etherx.jabber.org/streams"
to="jabber.org"
xmlns="jabber:client"></PRE
></P
><P
>There are four parts to this opening tag.</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
>The <TT
CLASS="LITERAL"
><stream:stream></TT
> tag itself</DT
><DD
><P
><TT
CLASS="LITERAL"
><stream:stream></TT
></P
><P
>Every streaming Jabber XML document must start, and end, with a tag named
<TT
CLASS="LITERAL"
>stream</TT
>, qualified with the <TT
CLASS="LITERAL"
>stream</TT
>
namespace.</P
></DD
><DT
>The <TT
CLASS="LITERAL"
>stream</TT
> namespace declaration</DT
><DD
><P
><TT
CLASS="LITERAL"
>xmlns:stream="http://etherx.jabber.org/streams"</TT
></P
><P
>The declaration of the <TT
CLASS="LITERAL"
>stream</TT
> namespace also comes
in the opening <TT
CLASS="LITERAL"
>stream</TT
> tag. It refers to a URL
(<TT
CLASS="LITERAL"
>http://etherx.jabber.org/streams</TT
>) which is a fixed
value, and serves to uniquely identify the <TT
CLASS="LITERAL"
>stream</TT
>
namespace used in the XML document, rooted with
<TT
CLASS="LITERAL"
><stream/></TT
>, that is streamed over a
Jabber connection.</P
><P
>The namespace qualifies only the tags that are prefixed
"<TT
CLASS="LITERAL"
>stream:</TT
>". Apart from <TT
CLASS="LITERAL"
>stream</TT
>,
there is one other tag name used in
these documents that is qualified by this namespace, and that is
<TT
CLASS="LITERAL"
>error</TT
>. The <TT
CLASS="LITERAL"
><stream:error/></TT
>
tag is used to convey Jabber XML stream connection errors, such as
premature disconnection, invalid namespace specifications, incomplete
root tag definitions, a timeout while waiting for authentication to
follow the root tag exchange, and so on.</P
></DD
><DT
>The <TT
CLASS="LITERAL"
>to</TT
> attribute</DT
><DD
><P
><TT
CLASS="LITERAL"
>to="jabber.org"</TT
></P
><P
>There is a <TT
CLASS="LITERAL"
>to</TT
> attribute that specifies to which Jabber
server the connection is to be made, and where the user session is to be
started and maintained.</P
><P
>We've already specified the <TT
CLASS="LITERAL"
>jabber.org</TT
> hostname,
representing our Jabber server, when defining the socket connection
(<TT
CLASS="LITERAL"
>jabber.org:5222</TT
>), so why do we need to define it
again here? As indicated by the <TT
CLASS="LITERAL"
>to</TT
> attribute,
you can see that we've made a <I
CLASS="EMPHASIS"
>physical</I
> connection
to the <TT
CLASS="LITERAL"
>jabber.org</TT
> host. However, there may be a
choice of <I
CLASS="EMPHASIS"
>logical</I
> hosts running within the Jabber
server to which our client could connect.
When making the <I
CLASS="EMPHASIS"
>physical</I
> connection from our client
to the Jabber server, we defined the hostname <TT
CLASS="LITERAL"
>jabber.org</TT
>
for our socket connection (to <TT
CLASS="LITERAL"
>jabber.org:5222</TT
>).
Now we're connected, we're specifying <TT
CLASS="LITERAL"
>jabber.org</TT
> again
as the <TT
CLASS="LITERAL"
>logical</TT
> host to which we want to connect
<I
CLASS="EMPHASIS"
>inside</I
> Jabber. This
is the logical host identity within the Jabber server running on the
<TT
CLASS="LITERAL"
>jabber.org</TT
> host.</P
><P
>This "repeat specification" is required,
because there's a difference between a <I
CLASS="EMPHASIS"
>physical</I
>
Jabber host, and a <I
CLASS="EMPHASIS"
>logical</I
> Jabber host. In
<A
HREF="x1740.htm"
>the section called <I
>A Tour of <TT
CLASS="FILENAME"
>jabber.xml</TT
></I
> in Chapter 4</A
> we see how a single Jabber server
can be set up to service user sessions (with one or more JSMs) that
are each identified with different logical hostnames.
This is where the <I
CLASS="EMPHASIS"
>physical</I
>/<I
CLASS="EMPHASIS"
>logical</I
>
hostname distinction comes from, and why it's necessary to specify
a name in the root <TT
CLASS="LITERAL"
><stream:stream></TT
> tag's
<TT
CLASS="LITERAL"
>to</TT
> attribute.</P
><P
>It just so happens that in the example
of an opening tag that we've used, that the <I
CLASS="EMPHASIS"
>logical</I
>
hostname is the same as the <I
CLASS="EMPHASIS"
>physical</I
>
one—<TT
CLASS="LITERAL"
>jabber.org</TT
>. In many cases, this will be
the most commonplace. However, an Internet Service Provider (ISP), for
example, may wish to offer Jabber services to its customers and dedicate
a single host for that purpose. That host has various DNS names, which
all resolve to that same host IP address.
Only one Jabber server is run on that host. (If a second server were to
be installed, it would have to listen on different—non-standard—
ports, which would be less than ideal.) To reflect the different names
under which it would want to offer Jabber services, it would run
multiple JSMs
under different <I
CLASS="EMPHASIS"
>logical</I
> names (using different
values for each
<TT
CLASS="LITERAL"
><host/></TT
> configuration tag, as explained
in <A
HREF="x1740.htm"
>the section called <I
>A Tour of <TT
CLASS="FILENAME"
>jabber.xml</TT
></I
> in Chapter 4</A
>).
When connecting to that Jabber server, it may well be that the
<I
CLASS="EMPHASIS"
>logical</I
> name specified in the opening tag's
<TT
CLASS="LITERAL"
>to</TT
> attribute would be different to the
<I
CLASS="EMPHASIS"
>physical</I
> name used to reach the host in the
first place.</P
></DD
><DT
>The namespace of the conversation</DT
><DD
><P
><TT
CLASS="LITERAL"
>xmlns="jabber:client"</TT
></P
><P
>In addition to the namespace that qualifies the <TT
CLASS="LITERAL"
>stream</TT
>
and <TT
CLASS="LITERAL"
>error</TT
> tag names—which could be seen as
representing the "outer shell" of the document, the
<TT
CLASS="LITERAL"
>xmlns</TT
> attribute specifies a namespace which will
qualify the tags in the body of the document; the conversation fragments
of XML which will appear over time.
This namespace is <TT
CLASS="LITERAL"
>jabber:client</TT
> and signifies that
the <I
CLASS="EMPHASIS"
>type</I
> of conversation that is about to ensue
over this document connection is a <I
CLASS="EMPHASIS"
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -