What port should use WCF HTTP transport based service? I created WCF service and Visual Studio assigned address http://localhost:7517/
But some customers can use web proxies and it seems that using standard 80 or 8080 is good idea, isn't it? How to force WCF client to use proxy to get to WCF service? From other side we should be confident that port 80 is not occupied by some web server. Is it correct to require from customer isolating WCF service on separate server to avoid collision? What is the best practice?
UPDATED: 80 port is bad candidate: system (Microsoft-HTTPAPI/2.0 for example) uses it often: Why is System process listening on Port 80?
Related
I'm planning on using a wsDualHttpBinding for a WCF service with callbacks. The clients will be a windows form application communicating to the service over the internet. Obviously I have no control over the firewall on the client side, so I'm wondering what is the proper way to set the ClientBaseAddress on the client side?
Right now in my intiial testing I'm running the service and client on the same pc and i am setting the binding as follows
Dim binding As System.ServiceModel.WSDualHttpBinding = Struct.Endpoint.Binding
binding.ClientBaseAddress = New Uri("http://localhost:6667")
But I have a feeling this won't work when deploying over the internet because "localhost" won't translate to the machine address (much less worrying about NAT translation) and that port might be blocked by the clients firewall.
What is the proper way to handle the base address for callbacks to a remote client?
some one tell me if i do not specify ClientBaseAddress then WCF infratructure creates a default client base address at port 80 which is used for the incoming connections from the service. Since port 80 is usually open to firewalls, things should just work.
so just tell me when win form wcf client apps will run then how can i open my custom port like "6667" and also guide me what library or what approach i should use as a result response should come from client side router
to pc and firewall will not block anything. please discuss this issue with real life scenario how people handle this kind of situation in real life. thanks
The proper way is to use TCP transport instead of HTTP transport. Duplex communication over HTTP requires two HTTP connections - one opened from client to server (that's OK) and second opened from server to client. This can work only in scenarios where you have full control over both ends. There is simply too many complications which cannot be avoided just by guessing what address to use like:
Local Windows or third party firewall has to be configured
Permission for application to run - listening on HTTP is not allowed by default unless UAC is turned off or application is running as admin. You must allow listening on the port through netsh or httpcfg (windows XP and 2003) - that again requires admin permissions.
Port can be already used by another application. In case of 80 it can be used by any local web server - for example IIS.
Private networks and network devices - if your client machine is behind the NAT the port forwarding must be configured but what if you have two machines running your application on the same private network? You cannot forward from the same incoming port to two machines.
All these issues can be avoided mostly only when you have control over whole infrastructure. That is the reason why HTTP duplex communication is useful mostly for intranet scenarios and why for example Silverlight offers another implementation where the second connection is not created and Silverlight client instead polls server continuously to check if there is any callback available.
TCP transport requires only single connection from client to server because TCP protocol is natively duplex so the server can call back the client through the same connection. When you deploy a public service you usually have control over infrastructure on the server side so you can make necessary changes in configuration to make it work.
I think this also answers your previous question.
We are planning to develop a big set of WCF-services with net.tcp binding (about 50 services). They will be hosted on IIS.
As I understand, there are two way to realize it:
Create one site on IIS. Services will be deployed as a IIS application. So, all service will use the same port according to net.tcp binding for site (net.tcp port sharing feature).
Create 50 sites on IIS, one site for one service. Every site will have different port in net.tcp binding - so, every service will work by using different ports.
What kind of way is better according to performance issues? I couldn't find any information about performance of solutions with net.tcp port sharing.
NetTcpPortSharing is the WCF TCP port sharing service. It implements a centralized TCP listener so that multiple processes can listen on the same TCP port.
For more information you can refer this link.
http://msdn.microsoft.com/hi-in/magazine/cc163357(en-us).aspx
Port sharing should not only be only one consideration to deploy your service.
You have to design your deployment based on.
Application Pool.
Crash and recovery.
Server Hardware.
Nature of services (heavy data transaction)
I have two processes running on the same machine. Each process is hosting a WCF service to allow inter process communications asynchronously. As of now, I have assigned a fixed port 8731 and 9000 to the two wcf services. What if a customer machine has these ports taken up? How can i dynamically make the wcf client find the wcf service if I were to dynamically allocate an available port?
Thanks for your help in advance.
I assume you're creating services in code. If you're afraid of the client not having those ports available, you should configure your endpoints using app.config. That way, if a client has an issue with a port, you can simply change their config file instead of recompiling your code.
I am late on this post, but today we have better solution for this problem.
There is a configuration endpoint known as listenUriMode(https://msdn.microsoft.com/en-us/library/system.servicemodel.description.listenurimode(v=vs.110).aspx), if we set this value to "Unique", it will bind hostname to port 0 which will ask OS to assign a free port.
Now client can know about the server port using WCF discovery(https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/wcf-discovery-overview).
I'm interested in one WCF server exposing both HTTP and TCP interfaces. It'll be used with Silverlight clients, so the thinking is that the HTTP interface will be for secure communications while TCP will be used the rest of the time.
Is it possible for these two interfaces to use the same port in their endpoints, e.g. http://localhost:9000/ and net.tcp://localhost:9000/?
No this is not possible. If you have the TCP port sharing service enabled, you can have multiple services listening on the same TCP port. Windows HTTP listener will also allow you to have multiple services sharing a common port (for example, a console application and IIS can both listen on port 80 at different URL's). But you can't use multiple bindings on the same port.
But I don't really see the advantage of doing that anyway. I would personally leave the HTTP endpoint on port 80 and of course your TCP endpoint is restricted to an upper port range. I'm not sure what scenario you're trying to enable though.
You can only have one "listener" on a TCP port, so unless the WCF server does some sort of protocol-level multiplexing (i.e. if it reads in an HTTP header, send it to the HTTP handler otherwise send it to the "raw" handler), you'll have to use different ports.
Of course the quickest way to find out is to configure your server with both of these interfaces and the same port, and check your logs for errors. Chances are each one will be attempting to bind to port 9000 from their own thread or process, and the second one will fail.
I could run a Windows Service hosted WCF service listening http://localhost:80/MyService while IIS was serving pages on http://localhost:80 and both works.
But many places in the internet (like this and this) say that only a single process can listen each port simultaneoulsy.
Are they wrong?
HTTP.sys makes this possible. From the article:
...because WCF and IIS 6.0 both use the kernel-mode HTTP stack (HTTP.sys), IIS 6.0 can share port 80 with other self-hosted WCF services running on the same machine...
HTTP.sys acts as a port-forwarding service, for HTTP (port 80) traffic.
Could it be that you are hosting the WCF service in IIS. So that IIS is sending the request to the WCF service based on the URL.
Edit:
It may be also that the WCF services were setup to do port sharing like this:
http://msdn.microsoft.com/en-us/library/ms734772.aspx
Edit2:
Ok, I reread your edited question, see the links in this answer:
http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/8993f7c5-1f78-4156-a131-d9b40af10d9a
"The IP Listen List allows WCF services to coexist with applications that use a port for some of the IP addresses of the machine. If the IP Listen List contains any entries, the HTTP Server API will only bind to those IP addresses that the list specifies."