I'm trying to understand the difference between the standard bindings in WCF. As part of this, I'm reading WCF Bindings in Depth. Figure 2 shows that there are bindings whose transport is HTTP and some which are TCP. I'm confused b/c I thought HTTP was an application-level protocol, not a transport protocol -- and that HTTP ran on top of TCP. So by calling it an HTTP binding, are we to understand that it's actually running on HTTP on top of TCP?
So by calling it an HTTP binding, are we to understand that it's
actually running on HTTP on top of TCP?
Yes, exactly. But that's implicit. Because HTTP runs on top of TCP.
The binary bindings (such as netTcpBinding) run directly on TCP. They do not use HTTP at all.
tcp/ip contains 4 layers:
application
transport
network
data link
you can use any layer, but wcf has binding which use transport and application layers, f.e. netTcpBinding and wsHttpBinding
tpc/ip does not same tcp layer
application layer protocols f.e.: HTTP, RTP, FTP, DNS
transport layer protocols f.e.: TCP, UDP, SCTP, DCCP
so http can be based at UDP protocol and it will be wsHttpBinding
or if you choise tcp it will be netTcpBinding, this layer in below than http, and application is redundant
Related
I am writing WCF services uses REST Messaging protocol. Am I correct by saying my WCF service is compatible with TCP/IP transport as well? (HTTP is by default anyways)
Firstly, REST isn't a protocol, it's an architectural style employed over the HTTP protocol. With that in mind, it's dependent on the HTTP Application layer in the OSI stack, so in essence, any Network layer (i.e TCP/IP) that has an implementation of HTTP above can be used for interfacing in a RESTful manner.
I have a RESTful service which is exposed via WCF with the webHttpBinding.
I am now asked to get the TCP header (specifically the packet TTL). The difficult approach will be to switch to the net.tcp binding and handle all the HTTP layer by myself.
There must be an easier way... Please help!
As you've found out, WCF abstracts the message transport (TCP, HTTP, ...) by implementing the binding concept (netTcpBinding, basicHttpBinding, ...). The benefit is to be able to easily (most of the time) change bindings without affecting the service code. The trade off for this ease is hiding the transport details from service code. In fact, its fairly difficult to get the client IP address in WCF.
On the other hand, WCF is so extensible that you can "re-implement" the webHttpBinding as a custom binding so you can bubble up the TCP info you want. This SO question & answer will give you a start on a custom binding but you'll likely need to create a custom HTTP transport component to access the TCP details. When a tool makes you work this hard, there's a good chance you're using the wrong tool. Just sayin' ... :)
I have small question,
If I host NetTcpbinding WCF service in IIS 7.0 and I want to invoke this service from Client application, then what format this will be used fo communication..??
Is there any rule saying that, all NetTcpbinding should not host on IIS instead they have to host on Console application or windows service..??
When extactly I want to go for TcpNet binding..??
Suppose, I have two endpoints one for WsHttpbinding and other one is NetTcpbinding and deploy Service in IIS then If I want to use NetTcp endpoint from Client application then how..?? Is this correct way to do...?? in this scenario...
Thanks,
Sukesh.
NetTcpBinding Class info:
http://msdn.microsoft.com/en-us/library/ms576421.aspx
Quoted from the remarks:
The NetTcpBinding generates a run-time communication stack by default, which uses transport security, TCP for message delivery, and a binary message encoding. This binding is an appropriate Windows Communication Foundation (WCF) system-provided choice for communicating over an Intranet.
Quote indicates that a Client-Server connection is established via TCP and this is used to send the SOAP Message encoded in binary.
2.
No. There is even this nice blog post on how to do it:
http://blogs.msdn.com/b/santhoshonline/archive/2010/07/01/howto-nettcpbinding-on-iis-and-things-to-remember.aspx
3.
Back to the class info:
More generally, the HTTP system-provided bindings such as WSHttpBinding and BasicHttpBinding are configured to turn things on by default, whereas the NetTcpBinding binding turns things off by default so that you have to opt-in to get support, for example, for one of the WS-* specifications. This means that the default configuration for TCP is faster at exchanging messages between endpoints than that configured for the HTTP bindings by default.
This means that this binding doesn't do all the higher level processing that basicHttpBinding and WSHttpBinding do due to the additional protocol layers expected (http layer and WS-* spec layer). So this is a higher performance binding configuration giving you a faster turn around time in your service message replies at the cost of losing your http layer (clients can no longer just HTTP POST soap envelopes to your service).
4.
I would set up two separate service endpoints(one TCP and one WSHttp) that implement the same interface. Then you can set up two client config items on the client end that again use different binding configuration but call to the same interface. Then you can just load either.
<client>
<endpoint name="WSEndpoint" address="http://address/WSEndpoint.svc" binding="WSHttpBinding" contract="Your.Contract.Namespace"/>
<endpoint name="TCPEndpoint" address="http://address/TCPEndpoint.svc" binding="NetTcpBinding" contract="Your.Contract.Namespace"/>
</client>
I am reading through the WCF 4.0 Cookbook, I am impressed by the unification protocol capability of WCF, and I just come up with this question:
Is a hosted service using 1 protocol like HTTP\named pipe? or a hosted service can be consumed by different protocol client like HTTP, named pipe at the same time?
If you setup the service with Multiple Bindings then yes it can listen and respond on different transport protocols.
Obviously if you initiate communication on http then you will get a response back over the same transport.
This msdn link provides details on when you would choose the different transports.
http://msdn.microsoft.com/en-us/library/ms733769.aspx
I have a simple pox operation using webHttpBinding and am specifying a security mode of transport to enable HTTPS. Once i do this though, I can no longer send http traffic to it. I'd like the option of both. How can I enable https while also keeping http?
You will have to create service with two WebHttpBinding endpoints. One endpoint will use HTTP (binding without transport security) and second endpoint will use HTTPS (binding with transport security). You will also have to configure your IIS to support both HTTP and HTTPS (assign certificate).
The question is if this is reasonable? If you really think that your service has to provide secure transport because of confidental data then providing unsecured endpoint in the same time doesn't seem like a good solution.