>> (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.

> - Firewalls

This is not a valid reason.

> 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*.

> 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.)

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

>> 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?

Post a reply to this message