On 12/11/2013 02:01 PM, Francois Labreque wrote:

>>> XML is a document formatting language. Not a transfer protocol. XML does
>>> not do error handling, retransmits, keepalives, etc... If you use raw
>>> TCP sockets, you need to reinvent all those wheels.
>>
>> You send an XML document explaining what method you want to call. The
>> server sends back an XML document either saying it went OK, or
>> describing why it didn't. Provided you standardise the XML, you don't
>> particularly need anything from the transport protocol.
>
> How would you implement splitting the payload across multiple packets,
> with a direct socket connection? How would your server know the
> difference between a malformed XML document with missing closing tags
> and a missing packet?
>
> How do you tell your server (or client) that there should be more data
> coming?
>
> How do you handle errors?
>
> The answer is to reinvent XML wheels that already exist in HTTP.

TCP already handles splitting a message into packets and reassembling it 
on the other side. Of the things you've mentioned, error reporting is 
the *only* thing TCP doesn't already do - and that's quite easy to deal 
with using XML. (HTTP lets you report a 3-digit error code. XML lets you 
report an entire stack trace if you wish.)

>>> In an entreprise setting. you need to do application layer parsing of
>>> your traffic to ensure that, amongst other things, PII does not excape,
>>> so using HTTP means that a third party firewall will be able to do deep
>>> packet inspection out of the box.
>>
>> How does HTTP have any baring on this?
>
> Everyone knows how HTTP is defined, so it's easier to find the relevant
> data in an HTTP stream, than in a proprietary protocol.

I don't see how parsing XML over HTTP is any easier than parsing XML 
over raw TCP.

>>> Also, HTTP is very easy to proxify, so your application will work in
>>> most entreprise settings, without having to resort to Socks, or other
>>> forms of tunnels.
>>
>> If you're trying to send commands and replies, the *last* thing you want
>> is some proxy caching it for you...
>
> I'm not talking about caching, I'm talking about relaying. Most proxies
> are indeed caching proxies, but their priamry function is to relay
> traffic from one network to another network and keeping both networks
> isolated.

I have no idea why you'd want to do that.

>> This is the fundamental problem with HTTP. It's designed to transfer
>> static documents, not ephemeral commands and replies.
>
> You are correct, that there are more specialized messagin protocols out
> there (most of them proprietary), such as IBM MQ-Series or TIBCO
> Rendezvous, just to name them, that are more suited to handling
> ephemeral commands, than HTTP, but most of the civlized world has no
> problems whatsoever using HTTP (or more often HTTPS) to exchange data
> between systems and even companies.
>
> Since the makers of WCF do not know ahead of time what you will be doing
> with their framework, they decided to pick the most widely used tranfer
> protocol to make most of their users' life less miserable.

I still don't really see why you need any additional services beyond 
what TCP provides. What do these proprietary protocols get you?

>> I don't see why you would ever need more than one TCP connection -
>> unless you're actually trying to issue multiple commands simultaneously
>> or something...
>>
>
> In your particular case, maybe, but you are using a general purpose
> framework that is built for general use.
>
> Let's say a travel agent is discussing various possible plane/hotel
> combinations with a client. She shouldn't "hog" a tcp socket open for
> minutes while the client makes up his mind, nor should she have to
> re-enter her credentials everytime she checks the availablity at another
> hotel, or makes the final reservation.
>
> In the background, the application would open one session and issue a
> session ID, after having verified the user's credentials. Then after
> that, whenever the travel agent makes a query through her reservation
> system, the client-side application would open a new TCP sessions,
> include the application ID inside the payload and send one (or more)
> commands to the server. The server would send the reply and the TCP
> connection would then close to leave resources available for the next
> agent.

You speak as if having a TCP connection open is some terrible overhead. 
If you're allocating a session ID, I would suggest that storing the 
details of this session somewhere is already using *far* more resources 
than a simple TCP connection...

Post a reply to this message