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.
Related
Suppose I have a thousand of hardware device(about 20,000) which send the data in real time. I have to capture this data and send all data to database and also show information in application.For this I am thinking to develop a WCF service which poll all the devices and get the data from devices and store in database.
So my question is "Is WCF efficient to do this or I should follow another approach "
I am thinking to develop a WCF service which poll all the devices
A WCF service cannot "poll". A consumer can poll, which is to say it can call a service over and over again, however there is no polling pattern built into WCF client channel. So any polling behavior will need to be programmed.
So my question is "Is WCF efficient to do this or I should follow
another approach "
What I suspect is that you actually want your devices to call the service and pass data, so what you are actually asking is Can a WCF service handle a high volume of calls?, to which the answer is Yes.
However, in order to get the best scalability you should expose a per-call service, and do this over netTcpBinding (basically sockets), which uses optimised encoding and is therefore higher performance.
This would only be available to a consumer running the WCF client stack. If WCF is not available on your devices then the next best option is probably an HTTP endpoint over webHttpBinding, which provides the best interoperability.
Can you please suggest some other technology?
Well, if you are happy using http on your devices you should look at nancyfx for hosting your service - it's a really nice, lightweight http container for .net.
I am researching doing a two way communication app, not necessarily peer to peer. Looking at using wcf, I am curious as to the inner workings on all of this. A big concern for me is NAT / firewalling.
I need to have this work without portforwarding on the clients. I will port forward the server, thats fine. but the clients need to be able to connect to the server, and then communicate back and forth through this now open (NAT and Firewall) connection.
The duplex wcf examples I am stydying, all seem to use a client address announced to the server to use for callback. Presuming this is a local lan adress, that wont work for public connections. If its the public address, port forwarding will be needed?
Am I missing something? I want to make a connection, keep it open, and use it in a duplex fashion. Thereby, getting past NAT and firewall restrictions once the client "dials out".
Further more, I am not quite sure on precisely how NAT is implemented. If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?
My final implementation would be:
Remote client <-> server behind port forward <-> management app issuing commands to the server which relays them to the remote clients.
Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.
Thanks for any insight provided.
EDIT: [PING-PONG] Hello Word?
With duplex services you can have independent communication between a server and clients.
Something to keep in mind about duplex services:
The duplex model does not automatically detect when a service or client closes its channel. So if a service unexpectedly terminates, by default the service will not be notified, or if a client unexpectedly terminates, the service will not be notified. Clients and services can implement their own protocol to notify each other if they so choose.
As far as the NAT/firewall settings preventing your services from working is indeed a good concern to have. However, your situation seems to fall in line with a typical two-way communication setup between client and server. I wouldn't suspect you having trouble getting things to work with a little bit of trial and error.
If I "punch" out a connection to a wcf service on port 5555, and receive a reply back, does port 5555 from / to that wcf service address stay in the NAT table? If I were to issue further connections from the server wcf service, and "connect" to a wcf service running on the client, (connect to the client public ip), will the NAT table know its me, and forward the traffic on to the client that initially punched the hole?
To my knowledge this is basically how NAT works. As long as the public IP of your server is accessible on port 5555 to both inbound/outbound traffic, you should be fine. You should maybe research or ask a question about this on Server Fault.
Am I barking up the wrong tree trying to use wcf? I started working on this using raw tcp a while ago, but picking up the project now again, I would like to go the wcf route to sort out all the overhead on rolling my own raw tcp communication.
I don't think you're barking up the wrong tree. It just depends on what you're trying to accomplish. WCF will do a lot of the heavy lifting for you and let you focus on the core of your application. However, if you're wanting to learn more about socket programming then rolling your own network API/library would be something to continue doing.
I am looking for an open-source framework that can handle communication between my backend host and a WPF frontend client. The following are points I need to consider:
Client is a WPF desktop app, host is a C# console APP but can also run as Windows Service
Host can accept connection requests, client connects, but I still seek bi-direction communication capabilities.
The client and host are not in the same network (need to send messages over the internet)
Just one (possibly more but less than 10) client will connect to the host.
I like to be able to handle the following communication patterns: One-way message, two-way request/response, and streaming from host to client.
The content will consist of serialized POCOs/DTOs and serialized time series data. Each serialized DTO will be of approximately size 400 bytes, the serialized time series can be a lot larger, potentially several megabytes.
Some messages will be sent scheduled, meaning for example, the host sends a new DTO every second. (if the framework includes such scheduling mechanism then even better)
I like to be able to stream data to the client, such as a client that receives and then updates data on its GUI in real-time.
My question is: What might be the best C# based framework to handle this? (I run on .Net 4.5) I do not consider WCF because it seems way too thick and complex for what I try to handle. I also do not want to delve into web programming, so Rest/Soap type frameworks are not under consideration. I would be delighted if anyone could recommend a tcp/websocket based framework or similar that is light weight enough to potentially send messages a lot more frequently than just every second.
Thanks a lot in advance.
Any reason why you are not considering HTTP? It is just over TCP but you don't need to worry about firewalls and stuff, especially given the fact that you want to do this over internet. Self-hosted ASP.NET Web API can be a good candidate. Fire and forget and request/response can be accomplished fairly straight forward and for streaming it has PushStreamContent. ASP.NET Web API is light weight compared to WCF and is open source. Just a suggestion, that's all.
I ended up using ZeroMQ for full-duplex communication between WPF client and Server. It is lightweight, very fast and pretty reliable for my needs.
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
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.).