>> TCP only ensures that data that is split in multpiple packets will be
>> rassembled in the right order at the other end. It does not tell you
>> ahead of time how much data to expect, so you can't know in advance if
>> you should still be waiting for the end of that XML document, or if it
>> was malformed and is missing closing tags, and you should simply
>> reject it.
>
> If the XML is machine-generated, it shouldn't ever be malformed. If it
> is, that's a bug.

A bug that has been exploited by many a malware.  ;-)  Trust no one!

> (Which I suppose is something real applications have
> to deal with, but it doesn't concern me overly much.)
>

True, but it is a good idea to develop good programming habits and do 
some error-checking nonetheless.

To reuse the powertool analogy that you and Warp are discussing, even if 
you develop the habit of wearing gloves and protective eyewear everytime 
you use your circular saw, even for small jobs, you have a much smaller 
risk of injuring yourself, the day you're tearing down the old kitchen 
counters and the saw hits a nail and jumps back at you.

>> To prevent unauthorized traffic from leaving or entering your network
>> (or parts of it). To mask the details of how the back-end of your server
>> farm is laid out. There are many valid uses for proxies, apart from
>> caching the Google Doodle of the day to speed up the users' connection
>> and cut down on bandwidth usage.
>
> Isn't that what a firewall does?
>

Firewall only inspect and block unauthorised traffic from leaving or 
entering a network, but for them to work, you need an actual route to 
the outside world to exist and point to the firewall.  With a proxy, you 
can actually NOT have any route to the internet on your inside lan. 
Your Proxy has two interfaces, one on the inside lan (and everyone uses 
that in their broswer config), and another one on an internet-accessible 
network.  This kills most bots and other malware dead.

In a corporate environment, you'd typically have such a setup to isolate 
the developpers (or "guest" wifi access, for example) from the rest of 
the production network, so that they can play as much as they want with 
their toys while still having access to needed intranet and internet 
resources, without impacting the rest of the business.

> The long and short of it is, I managed to configure WCF to *not* use
> HTTP, and it works exactly the same as if it *did* use HTTP. Which, to
> me, rather suggests that using HTTP is a total waste of time.
>

A 30 second google tells me that you can do something called 
"NetTcpBinding" instead of "BasicHttpBinding".  I have no idea if that 
is what you are looking for because I don't know how the framework works 
and this was just a blog entry explaining how to tell a server to say 
"Hello World!" and it didn't delve into the various intricacies of not 
using BasicHttpBinding.

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