>
> Most horrifyingly of all, it seems that absolutely everything to do with
> WCF defaults to turning method calls into XML data [which seems
> reasonable enough] and then transmitting it via HTTP [which is the most
> absurd thing I've ever heard of]. Almost nowhere does it tell you how to
> turn off the completely unnecessary HTTP layer and just run on plain TCP
> sockets.
>
> (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!)

- Firewalls

> So I deploy my new WCF code, and I hit upon *another* problem: It seems
> that after a while, the server disconnects for no apparent reason.
> Searching the Internet gives me nothing, until *eventually* I stumble
> upon a vague reference to ReceiveTimeout.
>
> Reading the scant documentation, it appears that if the server doesn't
> hear anything for this number of seconds, it disconnects the client. The
> intention seems to be that a client can't hog server resources by just
> connecting and then saying nothing.
>
> OK, a couple of things.
>
> 1. I can see how this might be bad if you were offering this service to
> the entire world (or maybe just a large internal network). However, I'm
> using this for 1 server with 1 client. This is an internal test
> framework. It will never be exposed to the outside world. I don't *care*
> about resource usage!

Then program a keepalive message at the application level.

>
> 2. Doesn't TCP *already* send periodic heartbeat messages and close the
> connection if it doesn't get a reply for a while? Why is WCF trying to
> duplicate this functionality when it's already present??
>

Not always.
TCP keepalive is an option and defaults to off.

Secondly, you may have many short-lived TCP connections part of the same 
long-lived application "session" (e.g.: online shopping, or http 1.0)

> Well anyway, all you have to do is go set ReceiveTimeout to some higher
> value. (The documentation is inconsistent, but I believe this defaults
> to 10 minutes - which is too soon, considering some of my tests take
> half an hour.)
>

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?

When you get put on hold, do you prefer hearing a "your call is 
important to us, please remain on the line to retain your calling 
priority" reminder ever minute or so, or just hearing dead air, not 
knowing if the agent hung up on you, or it looking at your file?

Client/server apps are the same.  If you want the communication channel 
to remain open, you should program a keepalive, and ideally an 
erro-recovery mechanism where it will try to reconnect in case the 
keepalive gets eaten by goblins.

> Oh, wait a sec... That works on .NET, but under Mono is has ABSOLUTELY
> NO EFFECT. Wuh?! O_O
>
> 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.


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