In addition to providing facilities for your program to speak the
standard XML-RPC language, XML-RPC For C/C++ provides facilities for
a variation on the standard that works in some applications for which
XML-RPC is insufficient, and is much faster. We call it packet stream
Packet stream XML-RPC does not use HTTP, as regular XML-RPC does.
Packet stream XML-RPC has a concept of a long-lived client/server
connection and you perform multiple RPCs over a single connection.
That connection is typically a TCP connection.
One advantage of packet stream XML-RPC over regular XML-RPC is that a
communicant can discover when its partner dies, no matter how violently,
because the connection goes away. So for example, imagine you have a client
that turns a machine on and off by sending RPCs to it. But if for any reason
the client isn't running, the machine should be in its quiescent off state.
To do this with packet stream XML-RPC, you could have the client create a
packet stream XML-RPC connection to the machine when the client comes up and
maintain it throughout the client's life. When the client shuts down, it
normally sends the RPC to turn the machine off before closing the connection,
but if the client should crash while the machine is on, the machine finds out
about it (because the connection dies) and turns itself off.
Another advantage of packet stream XML-RPC is that without all the
overhead of HTTP, it generally runs faster and with less CPU and
network resources. The lack of TCP connection setup and teardown for
an individual RPC also helps. Note that Xmlrpc-c's HTTP-based
facilities do HTTP persistent connections so that a stream of RPCs can
use just one TCP connection, which means this isn't as great an
advantage of packet socket XML-RPC as one might think.
Another reason to prefer packet stream XML-RPC is that the Xmlrpc-c
facilities for packet stream let you create the connection between
client and server independently, which gives you greater flexibility.
You create the connection, then hand it over to Xmlrpc-c for use in
performing or serving RPCs. So for example, one user had the problem
that he didn't want his client to have to know the server's IP
address; it was more sensible for the server to know the client's IP
address. With regular XML-RPC, this can't work because the client is
an HTTP client and has to initiate a TCP connection. But with packet
stream, he was able to have the server initiate a TCP connection and
the client merely accept it. With the complete connection in hand, he
invoked Xmlrpc-c facilities on the client side to send RPCs to the
You can use packet stream XML-RPC to maintain state across RPCs
too. For example, you can have a login RPC and then consider the
source of every subsequent RPC on that connection to be authenticated.
In regular XML-RPC, this sort of session is considerably more complex.
When you use it this way, you are straying from the RPC concept, which
requires that each RPC stand alone, but it might nonetheless be the
Packet stream XML-RPC is not a public standard. Only XML-RPC For
C/C++ implements it. So you use it only in applications where you
supply both client and server software, not in putting up a public server
for people to access with existing client programs or vice versa.
Only the C++ libraries (not C) offer packet stream facilities.
The Xmlrpc-c server facilities for packet stream XML-RPC are documented in
library manual. You also find details about the protocol itself there.
The Xmlrpc-c client facilities for packet stream XML-RPC consist of
the client XML transport class xmlrpc_c::clientXmlTransport_pstream,
documented in the
libxmlrpc_client++ library manual.