About WCF

  • Thread starter Thread starter Fred
  • Start date Start date
TCP is a binary protocol and messages passed using it will have trouble
passing through firewalls. HTTP is a text-based protocol and messages passed
using it will flow through firewalls without problems.

While TCP is faster, additional administration configuration will be
required and so HTTP is generally preferred.

-Scott
 
Dans : Peter Duniho disait :
Just to clarify: HTTP uses TCP, assuming you're using a TCP/IP network
(which is practically always the case). Both are technically binary,
though with HTTP the binary data is usually a representation of text.
HTTP does support transmission of non-text information...something
you use any time you download a file from a web server. So the
difference with respect to what gets through a firewall has nothing
to do with the format of the data as used by TCP versus HTTP.

The reason HTTP can be more reliable is that firewalls are generally
configured to at least allow traffic on port 80, which is what HTTP
uses. TCP is more generalized (TCP being the network protocol over
which the application-level protocol HTTP is usually sent), and so
it's harder to guarantee that a firewall, proxy server, NAT router,
etc. that might be in the network is willing and able to pass through
traffic on a non-HTTP port.
There are, of course, specific differences between the NetTcpBinding
class and the various ...HttpBinding classes that have nothing to do
with the actual network transport (default security, compatibility,
etc.). The above is addressing only the network configuration issue,
which may in fact be a relatively minor factor in the decision as to
which binding class to use.
Click to expand...

Thank you for your answers Scott and Peter.
So if I consider that configuration is not a problem, the choice is
driven by the functionnalities offered by the different binding classes.
Yes ?
 
Hey Peter,

I liked your clarification on HTTP. We are considering using a REST based
architecture for a new solution instead of using SOAP. My understanding is
that REST would be better for the solution because we would not run into any
trouble with any firewalls, because it would use HTTP. However, we've got
an argument here that SOAP basically runs over HTTP, so it shouldn't matter.
Basically, the argument is that SOAP would run over port 80 too.

Can you think of a good reason why we should use REST instead of SOAP?

Thanks.
-- Tom


Peter Duniho said:
[...]
So if I consider that configuration is not a problem, the choice is
driven by the functionnalities offered by the different binding classes.
Yes ?
Click to expand...

I believe so, yes. I'm no expert on the topic, but my understanding is
that the ...HttpBinding classes are generally going to be more
flexible/portable, at some cost in performance/efficiency.

My personal preference is to stick with the "more flexible/portable"
solution until such time as performance becomes a clear priority.
Performance is certainly worth considering, but it's often not important
enough to sacrifice the limitations and maintenance cost that
higher-performing code frequently brings.

Pete
Click to expand...
 
Back
Top