>>> (Seriously. HTTP provides *nothing* which is useful for transferring
>>> transient data. It's just pointless overhead. What the hell is *wrong*
>>> with the world? *Why* must *everything* be kludged to work over HTTP
>>> these days? Sheesh...)
>>>
>>
>> There are two reasons for this:
>> - Everybody and their grandmother knows how to handle HTTP. You don't
>> need to rewrite a custom interface to handle AndrewTP over port 31337
>> when you want to interface with the application. (Just dealing with the
>> XML parser is enough headaches already!)
>
> But this is *still* using XML - it's just that it's sending it on top of
> HTTP rather than over a raw TCP socket.

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.

>
>> - Firewalls
>
> This is not a valid reason.
>

Yes it is.

I'm not talkinf about hiding your application traffic inside of http 
octet streams to bypass the security nazis.

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.

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.

>> Then program a keepalive message at the application level.
>
> Right, so now I have to have a second thread sitting in the background
> with a timer, and I have to remember to reset that timer every time a
> command is sent, and then when the timer runs down, I send a null
> command and reset the timer... Surely all this boilerplate code should
> be in the framework?
>
> Seriously, when I used plain TCP, I didn't need to do this. The helpful
> framework is forcing me to do *more* work!
>
> (Well, technically it's not the framework's fault that Mono implements
> it wrong, but anyway...)
>
>> How does your client know the difference between the server processing
>> the request and the server having exploded in a firey ball of ones and
>> zeroes?
>
> No, this is the *server* not waiting for the *client*.
>

Well, it works both ways.  If your client got abducted by aliens (or 
more likely, bluescreened)  How long do you sit there wasting resources?

What if I just decided to start 65536 sessions on your server and let 
them idle?  Can you spell "Denial of service"?

You may not need this robustness in your isolated test bed environment, 
but the makers of the WCF framework can't (or shouldn't) assume that no 
one will ever release one of these apps into the wild.

>> Client/server apps are the same. If you want the communication channel
>> to remain open, you should program a keepalive
>
> This shouldn't be necessary. (And when it was plain TCP, it *wasn't*
> necessary, because TCP already implements this for you.)
>

As I mentioned in my previous message, there should be no relationship 
between the TCP connection and the application session.  Your 
application, over the course of a single user session, may need to 
create and teardown multiple TCP sessions with the same server.  Or at 
least, this would be the smart way of doing it.  You shouldn't have to 
rely on TCP's limited error-handling to survive a network glitch.

>> and ideally an
>> erro-recovery mechanism where it will try to reconnect in case the
>> keepalive gets eaten by goblins.
>
> It appears to be impossible to tell under WCF when the connection has
> been broken.
>

In that case, the framework is rather flimsy.

>>> OK, so under Mono it appears to be _impossible_ to stop the server
>>> disconnecting.
>>
>> At the risk of repeating myself... program an application-level
>> keepalive.
>
> The solution I eventually came up with was to connect, send one command,
> and then immediately disconnect. So now the program makes a new
> connection for every individual command. It's inefficient, but what else
> can I do?

Unless you plan on sending multiple commands in rapid fire, that's how 
it should be.  Yes, you sent 6 more TCP packets per "command", but your 
app is now much more tolerant of network glitches and doesn't waste 
resources on either end of the communication channel waiting for a 
client or server that is no longer there.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message