Index for bindings in this series:
Today continues the series I started last week about the standard bindings. The previous article covered the BasicHttp binding. Today’s article covers the NetTcp binding, which is going to be the popular out-of-the-box choice for communicating over an Intranet. The default configuration for TCP is faster than the configuration for HTTP, but intended only for WCF-to-WCF communication. You can open that up with a cost to speed, and you can add some WS-* specification features again at a cost to speed. There’s more about this in the article I did for choosing transports and message encoders. Whereas the HTTP bindings tend to turn things on by default, the TCP binding tends to turn things off by default so that you have to opt-in.
I’m again going to use the Security.Mode settings on the binding as my primary pivot for talking about the binding elements that are produced by the binding. The available settings are no security, TCP/SSL security, SOAP security, and TCP/SSL security with SOAP credentials. Let me repeat the presentation disclaimer I used previously because it applies just the same this time.
I’ve cut down on the number of properties presented by eliminating duplicates between the binding settings and binding element settings. For instance, the XML reader quotas can be set on either the binding or the message encoder binding element, but I’m only going to show them on the message encoder. I’ve also omitted most of the security credential settings because they’re very messy and you hopefully won’t need to change them much.
When Security.Mode is set to None, there are three binding elements in the channel stack.
AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)
And there are a number of loose settings on the binding not otherwise covered by these elements.
EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)
These are the baseline settings and all of the variations are very similar so I’m not going to repeat the properties unless they’re new or different.
Enabling Transport security adds a new binding element to perform the transform on the data stream. Note that unlike HTTP, the transport itself does not change and we do not integrate the transport security binding element with the transport binding element.
Setting Security.Mode to either Message or TransportWithMessageCredentials works almost the same as it did for HTTP. We take the channel stack corresponding to a Security.Mode of either None or Transport and add an additional binding element to perform SOAP security. The specific binding element used for security varies depending on both the Security.Mode setting and the security options that are being used.
Here’s an example with Security.Mode set to Message:
And here’s an example with Security.Mode set to TransportWithMessageCredentials:
Note that in all of these channel stacks, the transactions binding element was included even though transactions are disabled by default. The same is not true for reliable messaging. A binding element only appears for reliable messaging if you specifically enable that feature by setting the ReliableSession property to true.
I used Security.Mode set to None for this example, but reliable messaging works with other security modes as well.
Next time: Inside the Standard Bindings: NetNamedPipe