Adding XML over TCP/IP support would be nice. The topic is defined less
clearly, but this is what I know:
== message reading ==
Opening a socket for every call is too costly, so multiple messages can be
sent over a socket. XML parsers can't handle this, because they rely on the
end-of-file mechanism to determine when a xml-document is complete.
Some implementations rely on XML element recognition. When reading a
response message, the XML-tags are parsed, and when an closing
element is encountered that matches the first opening element, the
message is considered complete. With this example:
the message would be complete right after the string "</first-open>".
Most of the time, Xml parsing will not be needed, because the root-
element name is unique as a string within the Xml message.
Other implementations send an ASCII length header (decimal) before the
XML message: "0000056<?xml version="1.0"?><first-open><another/
== message matching ==
Often, more than one message can be sent, before responses are
returned ("window-size" is bigger than one). The responses also do not
need to be returned in the same order as the requests are sent. To match
the response with a request, one ore more textnodes in both the
messages have to match (transaction identifier).