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?
No.
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, fake, or mock object.
But in practice - in Win32, networking is accomplished using Winsock - which is 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.
