Develop Reference

Is WCF built on sockets?

I am trying to understand programming with sockets on a more detailed level rather than just with the API callings. I have fair understanding of C# WCF and socket programming using WinSocks in C++. Now I have 2 main questions:
Does WCF use sockets internally for the communication in all cases. In other words is WCF a wrapper around sockets and is built upon them?
Does all kind of network based communication use sockets at the end for sending/receiving data, which is something mandated by the OSI model?
A little detailed explanation will be better than just a Yes/No answer.

(With acknowledgement to the other SO users who agreed to reopen this question).
As an opening remark, remember that it's 2019 2020 and WCF is obsolete and I'm personally glad to see it gone, and I strongly recommend against using WCF for any new projects and I advise people to transition away from WCF as soon as possible.
Now, in response to your question (bold emphasis mine):
Does WCF use sockets internally for the communication in all cases. In other words is WCF a wrapper around sockets and is built upon them?
Strictly speaking, no (but in a practical sense, for inter-machine transport, yes).
WCF is a .NET platform that is concerned with "message processing". WCF tries to abstract away the underlying details of message transport (but it does so horribly, and so no-one should use it today), so it is entirely possible to build a WCF application that achieves inter-machine and inter-network communication without ever using Windows' Winsock, or whatever "Socket"-esque API is available for a given computing platform.
Now, while ostensibly WCF is all about abstraction, in practice WCF was geared around SOAP messages (and SOAP is horrible too, but that's another discussion), and SOAP primarily uses HTTP as a message transport - and HTTP primarily uses TCP/IP, and almost every single TCP/IP application on Microsoft Windows will be using the Winsock API somewhere in the process' communication stack. (It can be argued that HTTP applications on Windows will use http.sys which performs HTTP request/response processing in kernel-mode, which necessarily means bypassing Windows' user-mode Winsock API and instead http.sys uses "Winsock Kernel" which is its own thing).
In the above paragraph, note the use of the word "primarily" (as opposed to "exclusively" or "always") - because:
WCF doesn't have to use SOAP, it can use other messaging models/protocols/paradigms like net.tcp (which itself is more like a "binary SOAP") or even REST (though REST support came late in WCF's lifespan and it's a total pain to configure correctly, YMMV).
SOAP doesn't have to use HTTP, it can use other transports like SMTP. And WCF expressly supports other SOAP's other main transports like SMTP and FTP.
While HTTP is effectively tied to TCP/IP and Winsock is the only real way a user-mode application will use TCP/IP, other transports like SMTP don't have to use TCP/IP (at least, not in the way you think - see my footnote).
And of course, throughout all of this - user-mode applications are always free to use a different Networking Programming Interface besides Winsock or BSD sockets (for example, Windows' named-pipes present a streaming IPC interface just like how TCP behaves - or the vendor of a network-interface-card could have its own exclusively networking API which is somehow simply better than the Sockets API (similar to how GPU vendors in the mid-1990s were pushing their own APIs (Glide, PowerVR, Rendition, etc) until they all ended-up having to support Direct3D and OpenGL (and who uses Metal? hah).
And while WCF isn't exactly designed with testability in mind, it is still possible to host and run WCF applications inside an integration-testing environment where the actual message transport is just a thin proxy object, or a faked or mocked implementation - so Sockets are completely avoided there as well.
But in practice - in Win32, networking is accomplished using Winsock (Microsoft's implementation of the BSD Sockets API) so if you're using WCF to communicate between machines then I can say with 99% certainty that eventually your messages will pass-through Winsock.
Footnote: Regarding using WCF with SMTP without using Sockets: Many SMTP e-mail servers, including Microsoft Exchange Server, support "pickup directories" - which are filesystem directories actively monitored by the e-mail server, which detects when a new file has been added to the folder and reads each file as an SMTP envelope and processes it the same way as though it was an SMTP envelope received by the server's SMTP service endpoint - if a SOAP-in-SMTP message were to be "dropped" inside the pickup directory and it was destined for a recipient local to the pickup directory's e-mail service, then that message will not pass through Winsock at all either.

WCF Binding for non-WCF TCP Server

I have an old non-WCF Windows Service that creates a TCPClient to connect to a non-WCF TCP Server. I can't change the server app at all. It attempts to create a 2 threads, one for reading and processing messages from the Server, and one for reading from an MSMQ queue, processing, and then for sending to the TCP Server. Unfortunately, there are problems, and sometimes if there is a network disconnection I will get two instances of either the read or write threads. The threads share the same TCPClient connection.
Was hoping to switch my service to WCF, hosted by a Windows Service. I know I could use MSMQIntegration binding for a send method, but I am not sure how I could bind to a shared TCP connection. netTCPBinding seems to also be limited to WCF to WCF connections. Does anyone have suggestions on how to proceed?

This is theoretically possible with WCF's extensibility, but you would have to write a custom endpoint, a custom message formatter, and the fifty other classes. I'd recommend implementing the TCP service separately.
WCF Extensibility is best considered when you are dealing with a SOAP-like service which uses XML-like messages over a standard endpoint (transport). When you are "pretty close" to that, you can usually patch over the differences. When you are using none of that, WCF becomes a hindrance rather than a timesaver. For example, I would use WCF extensibility if:
I had a SOAP service which needed to run over SMTP or some other odd transport (custom endpoint)
I had a custom xml format that runs over a standard endpoint (I*MessageInspector)
I had a custom format which can be readily converted to XML running over a standard endpoint (custom message encoder)
I would not use WCF for:
Any format which does not convert readily to XML
Any format which does not readily identify the Action / target method
REST services (despite internal support - look at MVC Web API)
Anything requiring transport of large binary blobs (unless MTOM covers it)
Services where more than one of the built-in components have to be replaced

WCF library is the library that allows developers to communicate between WCF and non-WCF services in protocol agnostic way. Service developers using WCF don't need to known the details of protocol used between these services because these intricacies are hidden in WCF bindings. So the service developers have just to configure their client or server endpoints/bindings/behaviors correctly and these endpoints/bindings/behaviors do all the labor.
But WCF in not an universal platform to communicate with 'anything'. For instance NetTcpBinding uses TCP sockets to communicate. TCP protocol allows to create a pipeline between both parties but when this pipeline is established, TCP doesn't specify or mandate what content should be send through this pipeline. It can be some standardized protocol like HTTP, or proprietary custom protocol invented by SW developer that has never been published. There are hundreds maybe thousands of custom protocols that can flow through TCP including protocols like Modbus via TCP or IEC104. These 2 protocols for instance were specially designed to be tiny to communicate with the embedded devices and can't be used as the protocols for exchanging universal messages between Web services.
NetTcpBinding sends through TCP pipeline its own completely independent protocol designed by MS to provide efficient communication with WCF services build upon NetTcpBinding. It can't be used to communicate with your custom service using some unknown protocol with different (unknown) data serialization, timing, security, data exchange patterns, etc..
So the only viable option here is to use 'raw sockets' - classes like Socket or TcpClient to communicate with your proprietary service. But at first you must know what protocol your TCP Server is using. Maybe it's some standardized protocol like SOAP or HTTP or completely independent proprietary protocol that has never been published or documented.
And even though WCF has many extensibility options that allows developers to extend WCF library, these extensibility options are meant to be used when you want to allow WCF to communicate via other transport protocol (UDP, serial line, shared network path) or to add some new features to WCF bindings like new security option some extended transaction support or logging. But extending WCF to communicate with some non-WCF proprietary service (using some home-made protocol) would be inefficient (maybe impossible) and over-complicated.
So if your non-WCF service isn't using protocol that very close (virtually the same) as the protocol NetTcpBinding is using then WCF is not an option here. Use Socket or TcpClient classes.

Difference between WSDualHttpBinding and NetHttpBinding

I am writing a set of WCF services that will communicate with each other. I want to be able to establish a two-way connection between the servers. However, at some point, different types of clients (.NET or Javascript) should be able to communicate with these services.
I am currently using callbacks in WsDualHttpBinding, and it seems to do the trick, at least in a basic sense. Services can send basic messages to each other. My concern is opening multiple connections, as bandwidth might become a problem in the future.
I am fearful that NetHttpBinding is a much better tool to use.
I want to know what are some advantages or disadvantages of using NetHttpBinding compared to WSDualHttpBinding.

WSDualHttpBinding has a wider reach since it supports HTTP protocol.
NetHttpBinding however is faster by some margin since it works on nettcp in a network.

WSDualHttpBinding was created for a reason. WCF provided support for service 'callbacks' - methods on the client that were notified whenever service execution completed. Unfortunately, HTTP - being a one way channel - would not allow for callbacks (by contrast, the TCPBinding allows it since TCP is a full duplex channel). To get around HTTP's one-way nature, the DualHttpBinding was invented - two simultaneously open HTTP connections - one for the service request - and one for the callback.
NetHttpBinding is a binding designed for consuming HTTP or WebSocket services and uses binary encoding by default. NetHttpBinding will detect whether it is used with a request-reply contract or duplex contract and change its behavior to match - it will use HTTP for request-reply and WebSockets for duplex.

Difference between WebService and Remoting

I was comparing Web service with Remoting from performance and interoperatibility point of views
and have some doubts regarding it.
1) As Remoting support both TCP and HTTP channel, so is it when use TCP channel
It uses binary formatting and when HTTP, SOAP formatting
2) Can we use binary formating with HTTP protocol and XML/Soap formatting using TCP Protocol in Remoting
3) As Remoting supports XML/SOAP formatting which is universally accepted for any technology
and platform so it should provide interoperatibility between Server/client applications of
any technology/platform and if provide then what is use of web service.
As per my knowledge main advantage of Webservice over remoting is interoperatibility.
4) If I use Remoting with SOAP and HTTP, is it get bypassed by internet firewalls same way
as for web service or, still get restricted by firewalls.
5) Is any performance variation still exist if use remoting with SOAP formatting over
HTTP and webservice with SOAP formatting over Http.
6) Whether webservice support binary formatting and TCP Protocol as per my understanding
webservice only supports http prtocol but as per some programmers opinion in stack overflow
webservice is independent of transport protocol, so Is it like asp.net webservice only works on
http and web service developed in other technologies supports both TCP and HTTP.
Regards,
Arun Patil

If you use Remoting in HTTP mode, you WILL get past the firewalls.
While these two might seem they are doing the same thing, they are two different beasts. As an example, you can use interface types in Remoting, e.g. a service returning an interface, while this is not possible using ASMX Webservices (older stack) or WCF (only partially supported by KnownTypes), but on the other hand WCF supports multiple endpoints/bindings and better security and extensibility model than Remoting.
My advice would be if you are on a project already using Remoting, stick with it, otherwise it would not be a very wise choice to go with a technology that is, if not obsolete, won't get any new features so I'd suggest WCF for a green field project.

What are the benefits of using WCF?

We currently just utilize soap webservices for all our communication but have been thinking about moving to WCF instead. What are the benefits of using it over an asmx service?
If we do go with a WCF service, can other languages still communicate with it? SOAP is standardized and all languages can interact with it.
Are there any really good examples of how to get started with WCF that show the benefits of it over soap?
EDIT
I just found this question which is quite helpful.
The Getting Started Tutorial is great.

There's a bit of a learning curve with WCF, but once you learn it it's no harder to implement than an asmx web services. One advantage is you can easily switch protocols and serialization from binary remoting all the way to web protocols. It's also easy to host either in IIS or out.
Other languages can communicate with the web protocols. Binary, not so much...
I just dug into the Getting Started Tutorial. It does a good job of showing the relative ease-of-use. From there, take a look at Hosting and more detailed Features.

WCF is not a replacement for SOAP, and indeed, SOAP can be used as the serialization format between endpoints for communication. SOAP the standard also doesn't really define what goes in the message body, so in the case of WCF-to-WCF communication, a SOAP envelope is used, but the content is binary, so there's your primary advantage, at least in terms of performance. Another advantage is that the programming model of WCF is, or at least is intended to be, much more straightforward; especially since it sounds like you're really just using Web Services to communicate internally. In this case, most of the work would be up front, configuring endpoints (though consuming asmx WSDLs is obviously very easy in .NET).
I'm no expert in WCF, but what I do know has been from .NET user group presentations by Juval Lowy (who wrote the O'Reilly WCF book), his site has a decent amount of information in the way of screencasts and samples in the Resources section, in addition to the Microsoft sites (have you checked Channel9?).

Based on this MSDN article that is linked in the question, WCF supports more than just SOAP. It has support for:
BasicHttpBinding
Interoperability with Web services and clients supporting the WS-BasicProfile 1.1 and Basic Security Profile 1.0.
WSHttpBinding
Interoperability with Web services and clients that support the WS-* protocols over HTTP.
WSDualHttpBinding
Duplex HTTP communication, by which the receiver of an initial message does not reply directly to the initial sender, but may transmit any number of responses over a period of time by using HTTP in conformity with WS-* protocols.
WSFederationBinding
HTTP communication, in which access to the resources of a service can be controlled based on credentials issued by an explicitly-identified credential provider.
NetTcpBinding
Secure, reliable, high-performance communication between WCF software entities across a network.
NetNamedPipeBinding
Secure, reliable, high-performance communication between WCF software entities on the same machine.
NetMsmqBinding
Communication between WCF software entities by using MSMQ.
MsmqIntegrationBinding
Communication between a WCF software entity and another software entity by using MSMQ.
NetPeerTcpBinding
Communication between WCF software entities by using Windows Peer-to-Peer Networking.