I have a .net 4.0 WCF application that uses the net.tcp binding and implements some service.
I would like to set a TCP socket option for that binding (ReuseAddress option. A related question explains why I want to do that).
If I was working with Raw Sockets I could use the Socket.SetSocketOption Method.
Is there a way to somehow extract the underlying Raw Socket from the net.tcp binding in order to change its options? Or some other way to set this option?
Amir, Thank you for your suggestion of adding ReuseAddress option. However, we need understand better what was your concrete scenario. In the related question (Changing Socket Options on WCF net.tcp binding) context, have you enable port sharing? Seems like porting sharing could result with similar symptom. Basically, we need concrete repro program and setup steps to understand better of the problem.
If anyone still runs into the problem or see the need of adding reuseAddress option, please report the bug at http://connect.microsoft.com/VisualStudio with repro program and repro steps. Thank you.
Related
We set up a windows app that talks to a windows service for certain operations. It's set up and working using wsHttp but we need to add the url to the URLACL list for the service to run. Is this going to be an issue with other bindings as well, or are we basically just using the wrong one at this point?
In the future the service might be moved from the end user's local machine to a server on their network, so maybe we should use some other binding?
Seems like the "next" best option is netTcpBinding, but to use that you need to start the TCP Port Sharing service: http://msdn.microsoft.com/en-us/library/ms731810.aspx
Since the whole point was to simplify installation on client machines and reduce the number of changes to their configuration I'm not sure that gives any real advantage. I could convert to netTcpBinding for speed since it is the fastest protocol... but in this case it's fast enough to not justify more dev time.
Hate answering my own question, but hopefully this helps someone else down the line!
In Learning WCF, by Michele Bustamante, there is a section that describes a binding called the NetNamedPipes binding. The book says that this binding can only be used for WCF services that will be called exclusively from the same machine.
Under what circumstances would it make sense to use this? Ordinarily, I would write asynchronous code without using WCF... Why would Microsoft provide something for WCF that can only run on the same machine?
Look at it from the other direction. Once the service is built, you can run in in a variety of binding configurations. If it was a remote machine, you could use the HTTP or TCP bindings. Or, the service happened to be running on the same box, you have those options plus the named pipes option. The named pipes is just another option that is provided just in case you are running locally, but you should be able to switch to a different binding if you are running remote.
Yu could start with everything on the same box because you have less traffic, and use named pipes because it was the shortest path to the service. Then, if load demanded it, you can move the service to another box, and then change it to use TCP or HTTP instead.
You probably won't have a service that exposes only a NetNamedPipe endpoint - that doesn't make a lot of sense. But if you run your WCF service on a server, exposing service endpoints out to the world using the usual bindings, and you need e.g. a management or admin console or something like that, running on that same machine, it can make sense to use the NetNamedPipe binding since it's the fastest around.
Another possible scenario that I learned about is having an error collection service - any error or exception that happens is sent to a service to be logged. Again: that service would probably expose several types of endpoints, but if you have other services running on the same server, using NetNamedPipe binding to connect these two services makes a lot of sense.
I don't think you'll use the NetNamedPipe binding an awful lot in your WCF days - but it can definitely make sense in some cases and be quite useful in such specialized scenarios.
I want to communicate xml serialized objects from the server to the client and the other way arround. Now it is (probably) easy to invoke methods from a mobile client (compact framework) using WCF, but is there a way so that the server can invoke methods on the client side or some other way to pull data from the client? I know that callback contracts are not available in the compact framework as you can see here: http://blogs.msdn.com/andrewarnottms/archive/2007/09/13/calling-wcf-services-from-netcf-3-5-using-compact-wcf-and-netcfsvcutil-exe.aspx
Originally I thought of socket programming and of developing this by myself, then someone here mentioned WCF. But it seems like WCF only would work in a non mobile environment as I need callbacks.
Anyone can help me with this? Is it possible to develop a two way communication with a desktop server and multiple mobile clients using WCF, or will I have to do socket programming?
Thanks for any advice or any kind of help!
at ctacke
Thank you for your help. I actually stumbled across your Padran web server before.Havent really checked it out yet. But I definitely will do that later on. Anyway, a socket solution does not seem that bad at the moment. In the meanwhile I figured that it is quite easy to send data from multiple clients to a 'socket server'. If I can manage those connections somehow I can send data back to the clients. And then I would have to come up with some kind if protocol which handles the data or commands I send over the network... I guess the hardest part would be to make up such a protocol as I do not have a clue about that atm...
Even if you go to sockets it might be a bit difficult due to routing, carrier filtering and NAT translations (you've not mentioned what your actual network topology is). This is the reason that most mobile applications have to poll the server, even if it is a "push" paradigm (like Exchange's push mechanism, where the client actually polls).
Generally speaking, unless you're on something like a local wireless network where you have solid, routable, unfiltered network access, the client should periodically call the server and ask if the server has data. If it does, then it pulls the data from the server.
EDIT
Now that we know a little more about your topolgy from your comment, I can steer you a little more. Unfortunately Microsoft has not made it easy for Windwos CE devices to host services (WCF or otherwise). There is, in theory, the required infrstructure to build up your own WCF channel and actually host a service, but it's not a trivial task. I looked into it quite some time ago and figured it was a couple months of work and that would have been with the assistance of someone in Redmond that knew how the existing Exchange channel works.
Personally I'd opt for hosting a REST-based web service using our Padarn web server because it's simple to do and I've done it for quite a number of clients now. I realize that it's a little self-serving to propose Padarn as a solution but the entire reason I implemented custom IHttpHandlers in Padarn was because I couldn't find anything else out there that really provided any easy way for a CE device to host it's own services and it's a problem we often have to provide a solution for.
The other options would be things like a proprietary socket solution, hosting an FTP server on the device, using the (abhorrent, IMO) MS-provided HTTP server with ISAPI, Telnet or something along those lines. All of them seem either a hack, a lot of work or both.
Just starting to look into WCF and came across the
WSDualHttpBinding binding.
I have used .Net remoting in the past, but it was not possible to have callbacks to occur when the client was behind a router.
Callbacks only worked when 2 applications were running on a LAN.
As explained by this article.
http://blogs.msdn.com/manishg/archive/2004/10/16/243414.aspx
It mentions
“If your client application is running behind a router (as in the case of most home networking setups), there is no way for the server to dispatch events to the client”
Does WCF find a way of rectifying this, I understand the binding TCP supports callbacks only works on a LAN? Am I right? It would good to have callbacks work across the Internet and was just wondering if this was possible?
Not yet. The new relay bindings in WCF 4.0 rectify this for real, but the dual bindings are just a way to define server to client callbacks in a single contract.
Am wondering if anybody has tried this a technique to get events to the client from the server side. I have an environment that uses Unix based servers and so can't use WCF duplex / callbacks etc.
The idea being that my clients are windows boxes running a thick .net app would spin up a WCF self host and register their self host URL on the server for that session. They would have a very simple contract and the server would when it has an update call out the client server telling it that an Update is waiting on the server for it and the client would then get it etc.
I still trying to get my head round WCF so not sure if this is a good way to go, are there any security implications I should worry about ? are there ways to get the Duplex calls to work across platform.
I have done something similar before using sockets or maybe a cross platform message queue would be a better way to go on this anyhow.
Thanks
76mel
At the very least, that sounds like it ought to work, though I'd guess you could host in IIS as well since the *nix servers could then just make a web call, right? I'm not sure what self-hosting would gain you, though it should work fine, but might be a bit more of a pain in the neck to configure, etc.
Please update here whenever you've made a decision because it sounds like an interesting challenge and some of us would like to see how you make out.
We use self-hosted WCF for a similar scenario. We also wanted to avoid making our client application dependent on IIS, to prevent both licensing and deployment hassles.
It works fairly well for us, though WCF might be overkill for what you need. Since you're using HTTP, you could create a simple web service built directly on Http.sys.
Another way of getting similar results could be to have the client poll. This does depend strongly on what requirements are there. If you need a near real time update, this obviously doesn't work as you would have to have way to many polls to do this, but if it's ok to take a minute or more to get updates to the client, polling might just be the answer.