I have some requirement where i need to configure WCF service over TCP/IP protocol. I am able to do that by adding end point.
Client which is going to consume service will use some tool to push information. That tool take only IP address and Port Number.
Now i need some way to invoke service method by default on hitting IP with TCP/IP port. Is there any way to implement this? Or any workaround for this?
What i need is that there is some method in service i.e. UploadFile.
Service is using netTCPbinding. I have hosted it on server. so the URL
is something "net.tcp://XXX.XXX.XX.XXX:8080/XXXXServices.svc/mextcp".
Customer is using this for consuming. BUT the problem is my customer
using some tool which accpt only IPAdress and Port No over TCP. I am
trying to configure service in such a way that when he sent, data by
default UploadFile service get called. I hope it's make sense.
Thanks!
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.
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).
How can I configure my WCF service to work as a normal TCP server? Is it possible to disable all that binding specific stuff so as to keep your service URL like http://example.com:4444/service and be able to work vith pure HTTP/TCP streams?
I need to be able to work with TCP streams in tandem with WCF services... so I have to make TCP server from one of my WCF services or (and I do not know how) make my self-hosted WCF services work in pair with my stand alone TCP server. However, I just can not find how to make them share the same port so as to be able to call http://example.com:4444/WCFservice/ http://example.com:4444/TCPserver/ (And I have to make them share it; taking 2 ports is not an option.)
The easiest way to add TCP endpoint to the service is modify you web.config file with respect of "WCF Service configuration editor". You can find it in the "Tools" menu of Visual Studio of in context menu of web.config (also in VS). You need add new endpoint with netTcpBinding. The address of such new endpoint will be start with "net.tcp://". For more information you can read http://msdn.microsoft.com/en-us/library/cc949080.aspx.
For net.tcp port sharing read http://msdn.microsoft.com/en-us/library/aa395195.aspx or google for: wcf tcp endpoint port sharing.
A good review of new features of WCF 4 you can find in http://msdn.microsoft.com/en-us/library/ee354381.aspx
And take it easy if somebody don't understand advantages of WCF compares with Winsocket programming. 15 year ago I used sockets and find it cool. Then I used RPC, DCOM etc. Now WCF is the best way if you think about authentication of your endpoint. So take some of previous comments easy.
If you want to work with pure TCP streams you'd probably work with sockets directly and not WCF.
Use WCF when you want things auto implemented for you at the transport layer.
This is probably a basic networking issue, but I am new to this stuff and just do not know the answer.
I have written a wcf service and client. I can use one of the http bindings and get the service to work correctly when I put my machine's network IP address as the endpoint address and run the client and server from the same machine. Now, I want to be able to connect to this service from a different machine over the internet. Clearly it does not work when I use my network IP address in this scenario, but simply putting in my router's broadband IP address does not seem to be doing the trick, either. Am I just missing a firewall port that I need to open up, or am I trying to do something that should not be possible?
If you want users from the internet to be able to connect to your service, you'll have to consider a few points:
binding: the lowest common denominator is the basicHttpBinding which is SOAP 1.1 with basically no additional features available - just like ASMX webservices. Just about anyone can connect to that. For more advanced clients, you might also want to expose a wsHttpBinding endpoint on your service
security: how (if at all) do you want to secure access to your web service? Do you have username/password credentials that callers must supply? Check out the WCF Security Guidance for a whole slew of information bits on the various security scenarios
authenticating your service: typically, you should strive to make your service authenticate itself to the rest of the world - this requires a server certificate and enables secured communication (messages signed + encrypted) on the wire
make sure your service endpoint(s) is reachable from the internet, through all firewalls and proxies and everything :-)
Hope that helps a bit!
You need to set up port forwarding on your router. Perhaps someone on ServerFault or SuperUser would be able to help you. Or even a google search now that you know what it's called. The instructions will be different depending on the router. The port you need to forward will be the port you've picked in the WCF config file.
I host WCF services through IIS, but it took me ages to work out how. At the moment I put the files on the webserver and enable websharing on the root folder. Then you can assign them to an appropriate Application Pool in IIS, and add a service reference to any client projects using the URL of the wsdl.
I'm not sure if this is the best way to do it but its the only way I've worked out so far.
Here's the simple solution.
I am assuming that you have made a working WCF application and hosted over the IIS.
The next thing to do is to browse the application from the IIS. It will give you url in the address bar something like:
http://localhost/myservice/service.svc
Next go to www.whatismyip.com. this will give you your system's WAN IP (say, 45.34.56.200).
Replace the URL you got in step 2 with: http://45.34.56.200/myservice/service.svc
Now you can use this URL any where in this world to consume your service.
I found a good Article and it is working fine for me, on the following the Main steps:
1-First you should create WCF Service.
2-add application on IIS and give alias for your virtual directory and set path from your local drive.
3-Make sure your default app pool set to .NET CLR V4.0.
4-test your WCF service is running successfully on localhost.
5-To access the same via LAN (Local Area Network) you must disable Firewall for you Private network.
6- try to use ngrok.com, you will get Temp URL to use via internet to access your LocalHost anywhere.
Then Everything will be fine.
For More Information Check the following Link:
https://www.codeproject.com/Tips/813650/Host-WCF-on-LocalHost-and-access-via-Internet
I have a WCF service currently using a TCP endpoint. Rather than create a separate console client app to administer the server I want the ability to telnet into the server or even just connect using a raw connection using putty and execute ascii commands straight on the server.
Any ideas how I would go about doing this? Not an expert on WCF so would appreciate any help. Thanks
I doubt you could do that - WCF will always have to use its defined endpoints - TCP, HTTP - whatever. I am not aware of any telnet binding or raw connection, as you mention it.
From my perspective, why not create a service contract for admin purposes and just hit that with HTTP and/or TCP from a console app? Seems easier than trying to "bolt on" something that's not really been thought of.
Marc
To administer my WCF apps, I host in IIS, and have a subfolder in the application virtual directory with Admin aspx pages. The folder is protected from unauthorized access using ASP.NET roles.
The Admin folder includes application-independent pages (e.g. managing logging, view log files) and where appropriate application-specific pages.
Since the ASP.NET pages execute within the same AppDomain as the hosted WCF services, the sky's the limit as far as adding functionality for instrumentation and dynamic configuration.
I don't think WCF support custom command processing out of box and it will be quite a bit of hoop jumping to get that to work. I would suggest
Host the WCF service inside a windows service rather than IIS
Create a socket listener inside the windows service listening on the port of your choice
Write some code to process your command when data arrives the socket