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 XML-RPC.

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, you could have a client that turns a machine on and off by sending RPCs to it. If for any reason the client isn't running, the machine should be in its quiescent off state. So The client creates a packet stream XML-RPC connection to the machine when the client comes up and maintains 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 (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 server.

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 best design.

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.