what's the difference between net.tcp and TCP protocol?

I am reading the < Learning WCF > by Michele Leroux Bustamante. In this b开发者_StackOverflow社区ook, when it comes to net.tcp protocol, the author just says TCP instead. So what's the difference between net.tcp and the famous TCP protocol?

And as in net.msmq, net.pipe, what does the net prefix mean?

Many thanks.

net.tcp is simply the URI scheme used within Windows to identify endpoints that can be accessed using TCP.

Similarly, net.msmq and net.pipe, are the URI schemes to address endpoints that utilise the MSMQ protocol and Named Pipes protocol, respectively.

The net prefix on all three indicates that the URI scheme was devised solely for use on the Microsoft .NET platform and is not generally accepted in the wider internet. (Other URI schemes, such as http and ftp have have generally accepted meanings and are therefore utilised within WCF without any prefix). The net prefix therefore serves as an warning bell that the associated endpoint will have limited/no interoperability with other applications that are not running on the .NET platform.

Example URIs:

net.tcp://localhost:7272
net.msmq://somemachine/publicQueue
net.pipe://machine.domain.com/somePipe

SIDEBAR: While MSMQ and Named Pipes are clearly Microsoft protocols and therefore a lack of interoperability is unsurprising, TCP is the foundation protocol of the internet and therefore, surely it's use in WCF should not be .NET specific?

Well, interoperability in WCF is already handled by SOAP and HTTP, which both run on top of TCP. If you want interoperability over TCP - use one of those protocols.

Microsoft was therefore looking to provide a communication alternative where performance, rather than interoperability, was the key objective. TCP was the logical choice, but TCP is a relatively low level protocol, which requires additional behavior and defaults to be implemented in order to work in a straight-forward manner for a messaging framework like WCF. In addition, there is no generally accepted URI scheme for TCP accessible resources and therefore Microsoft needed to invent one. Thus, net.tcp was born.

While the URIs themselves don't necessarily indicate exactly which binding to use, they do provide a hint. As per Simon Mourier's answer, the bindings currently available within WCF can be found here. So, for instance, a net.tcp address could indicate that NetTcpBinding, NetPeerTcpBinding, or NetTcpContextBinding is required.

net.tcp lives in the Service Model (WCF) namespace. It's represented by many classes, the most visible being NetTcpBinding Class. So, essentially net.tcp is a WCF binding ('A secure, reliable binding suitable for cross-machine communication.').

So, net.tcp can only be used in the WCF context, and is simply based on the TCP protocol. But you can't say net.tcp=TCP. net.tcp just uses TCP. Compared to other bindings, it's considered as performant, but not interoperable.

The story is the same for net.pipe, net.msmq, they are WCF bindings implemented over lower Windows technologies, respectively Named Pipes and MSMQ.

Here is a list of system provided WCF bindings: System-Provided Bindings

Those are protocols set up within the Microsoft stack as additional options in WCF communications. Basically, tools you can use for your services to communication. Be aware, however, that while each one may have varying benefits, the net* protocols that Microsoft put forth for WCF do not play well with non-WCF (and non-Microsoft) consumers of those services. If interoperability is a concern, they may cause headaches later.

The prefix .net suggests that the framework authors have wrapped the protocol to provide you with an API that hides complexity and makes it easier for developers to use it.