I am currently working in socket based technology where my client(C++) and Server(.Net) uses
socket based communication to send and receive data,but now I am looking to replace my existing socket server with WCF. I want to clarify it completely before doing any such movement
1) Is it possible to replace existing socket and if yes how can I do this.
2) Server socket application listen at defined IP/Port and client socket application send request to that IP/Port only, but in case of WCF there is complete URI i.e. with IP/Port it also contains name of WCF Service, so how to do this.
3) Which type of binding configuration I need to use for it and if it is basic or wshttp can't it will effect performance of my application drastically.
When we use socket programming we do it at very low level and neither wcf, web service or remoting can perform good as compare to socket application. WCF provides so many feature but all this features are based on binding configuration and all this are at very high level as compare to socket application, so as far as performance is concern socket application will perform well as compare to wcf and if this are already build no need to replace it.
This is a rather difficult one to answer without knowing all the details of your application so I am going to attempt to answer this in a different order than you have asked it.
2) WCF supports multiple transport configuration. These are not limited to HTTP. For instance, the net.tcp transport doesn't use http at all but it does implement some complex functionality which you would need to replicate on the client side. For example Message Framing. This limits you choices to one of the standards-based approaches (unless you like doing that stuff).
3) Yes the http transports will probably be slower than direct socket communication. You will need need to profile exactly what features you require from WCF and what performance you need as there are many different configuration options which can have an impact on this.
1) So I guess this is the main answer. Yes it is possible but you will be required to make changes on both the client and server. While it is potentially possible for you to extend WCF to support your existing socket messaging format this could be a difficult and costly development process. Therefore you would want to implement this using Web Services (aka one of the http bindings) as opposed to net.tcp, msmq, etc.
Please note that WCF is actually extremely configurable with each layer having the ability to define custom transports, messaging, security, etc, etc. I would therefore suggest you read the documentation
Related
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.
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.
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.
I'm writing a client/server architecture where there are going to be possibly hundreds of clients over multiple virtual machines, mostly on the intranet but some in other locations.
Each client will be gathering data constantly and sending a message to a server every second or so. Each message will probably be about 128 characters or so in length.
My question is, for this architecture where I am writing both client/server in .NET is should I go with WCF or some socket code I've written previously. I need scalability (which the socket code has in mind), reliability and just the ability to handle that many messages.
I would not make final decision without peforming some proof of concept. Create very simple service, host it and use some stress test to get real performance results. Than validate results against your requirements. You have mentioned amount of messages but you didn't mentioned expected response time. There is currently discussed similar question on MSDN forum which complains about slow response time of WCF compared to sockets.
Other requirements are not directly mentioned in your post so I will make some assumption for best performance:
Use netTcpBinding - best performance, binary encoding, requires .NET server / clients. I guess you are going to use Net.Tcp because your other choice was direct socket programming.
Don't use security if you don't have to - reduces performance. Probably not possible for clients outside your intranet.
Reuse proxy on clients if possible. Openning TCP connection is expensive if you reuse the same proxy you will have single connection per proxy. This will affect instancing of you services - by default single service instance will handle all requests from single proxy.
Set service throttling so that your service host is ready for many clients
Also you should make some decisions about load balancing. Load balancing for WCF net.tcp connections requires sticky sessions (session affinity) so that after openning the channel client always calls the service on the same server (bacause instance of that service was created only on single server).
100 requests per second does not sound like much for a WCF service, especially with that little payload. But it should be quite quick to setup a simple setup with a WCF service with one echo method just returning the input and then hook up a client with a bunch of threads and a loop.
If you already have a working socket implementation you might keep it, but otherwise you can pick WCF and spend your precious development time elsewhere.
From my experience with WCF, i can tell you that it's performance on high load is very very nice. Especially you can chose between several bindings to achieve your requirements for the different scenarios (httpBinding for outside communication, netPeerTcpBinding in local network e.g.).
Tooday I use ServiceHost for self hosting WCF cervices.
I want to host near to my WCF services my own TCP programm for direct sockets operations (like lien to some sort of broadcasting TCP stream)
I need control over URL namespaces (so I would be able to let my clients to send TCP streams directly into my service using some nice URLs like example.com:port/myserver/stream?id=1 or example.com:port/myserver/stream?id=anything and so that I will not be bothered with Idea of 1 client for 1 socket at one time moment, I realy want to keep my WCF services on the same port as my own server or what it is so to be able to call www.example.com:port/myWCF/stream?id=222... and I want it to work on Any port - not only 80)
Can any body please help me with this?
I am using just WCF now. And I do not enjoy how it works. That is one of many resons why I want to start migration to clear TCP=)
I can not use net-tcp binding or any sort of other cool WS-* binding (tooday I use the simpliest one so that my clients like Flash, AJAX, etc connect to me with ease).
I needed Fast and easy in implemrnting connection protocol like one I created fore use with Sockets for real time hi ammount of data transfering.
So.. Any Ideas? Please - I need help.
Well if you're going to drop down to pure sockets, you could as well make your service act as proxy. Make WCF Services listen on some other port, and your app on the desired port. When you receive request in your app, manually parse header and check weather it is intended for your service or WCF Service. If it's intended for WCF service, open a TCP connection to WCF service and pass the received data to it, and then simply pass back WCF's answer to the client..
On the other hand you could speed up WCF quite a lot by writing your own custom binding. Lots of time WCF looses on serialization that is done using reflection (which is slow), going around this would improve your speed considerably.
If your problem with WCF is performance then you should try the binary net TCP binding to eliminate XML serialization to improve performance.
Some high traffic applications, like realtime games, use UDP for the majority of communication since it cuts through the protocol. With TCP you get ordering and reliability built in, but this comes at the cost of performance because it will implicitly delay packets to wait for out of order packets so that it can hand them to the application in the correct order, or wait for lost packets to be resent. Instead you can use UDP and implement your own scheme for verification of data that is less stringent than TCP.
There are UDP options available for WCF, or you could implement your own. WCF is nothing more than a message pump, and you can replace different steps with whatever you want.
Not sure if this will help you or not, but try turning on your Net TCP Sharing Service.