Im trying to make a a cleint/server web application where eventually the client application will be deploy on the internet. People told me to use visual studio WCF duplex but im confuse on how that works. I know for a simple server/client application using sockets, u can just use console for the server and then a windows form for the client.
So how does WCF duplex work, will it be used for both the server and the client side or do i sill use console for the server?? Also how do they establish a connection, in sockets you use ip address and a port.. HELP!
There are many WCF bindings that enable full-duplex communication. WCF servers and clients are able to use sockets among other means of communication. With WCF you can still use the IP Address:Port address system to expose and consume services.
With WCF you still can use Console Apps, Windows Forms or Web Applications to expose or consume those services. It brings no restriction at this point.
WCF will provide flexibility, since once you want to change the binding or the address, you can do it in the configuration file, instead of doing it by changing the code.
Related
I need to host ASP.NET based app as Azure Web App which should communicate with WCF based Azure Web App. ( WCF app is also an azure Web App not an on-premise app at all).
What are possible ways to achieve easy and flexible communication between both app services?
Do we need to establish a communication channel specifically?
Both Apps under IIS On-Premises are used to communicate without any problem over NET TCP protocol. But I think now we need both services to communicate over HTTP instead of Net TCP?
What problems we may have?
What things do we need to bear in mind?
First of all, we need to be clear that azure webapp only supports ports 80 and 443.
Secondly, in your project, you said that it runs normally in local, because I don't know what you mean by communicate, and I don't know how to achieve it. Normal communication may be socket or websocket, etc. It is not clear what communication you are talking about. If it is socket and you need to use a port other than 443/80, then it is not supported.
But I know clearly that azure web app supports wcf, which means that both of your webapps can be deployed successfully and run normally. If there is a problem, you can update the error details in the post, and we can provide you with further assistance.
I need simple way of communication between 2 desktop application over local network. Client application have to call server and trigger command execution on server desktop. RPC is the old way of doing that. Looks like WCF is new way.
If WCF, does it require IIS on the computer that is running server application?
Where I can find WCF sample code to follow?
For two Windows applications, you're probably going to want a self-hosted WCF service using Net TCP binding.
Self-hosted means the service is contained in your application (could be a desktop app or Windows service) - no IIS required. Just about any kind of binding will work, but Net TCP binding is ideal for .NET applications that only talk to other .NET applications over a LAN.
Here's a sample from MS on self-hosting.
You can host WCF in various ways - IIS, windows service, console application.
So no, you do not need IIS installed unless you want to host it on IIS.
Here are some examples on how to do it
Host a WCF Service in a Managed Windows Service
Host WCF in a Windows Service Using TCP
I am creating a client application that downloads and displays market data from Yahoo! for a university project, but that also sends out notifications to mobiles (so far using Google cloud messaging). So far it's a WPF client and the "server" is a class library - so far working. What I was wondering, is can you mix this server with a WCF service - the WCF service I was planning on using for registering devices, as well as accepting and parsing commands.
So I would call .Start() on my server object, and it will be constantly running in the background, while a WCF REST service runs alongside it - or would I be better simply having a thread running on the server that can accept input... sorry if this is confusing, but just wondering if it can, or has been done before or any advice. :)
Just to explain a bit better
The client front end and the "server" are running on the same machine - I was calling it a server because it is not only updating the front end, but sending out GCM notifications at the same time. I was wondering if maybe a WCF service could be added to make it simpler to handle adding devices to a database ("server" reads a list of device reg ids from a database, sends notifications to these) by allowing an android app to details via REST or something similiar
I would explore wrapping the class library in a Windows Service (which is essentially a process that runs continuously, and can be stopped/started/paused) and keep your WCF service as a web service for client communication.
How the WCF client service communicates with the Windows service is up to you - whether you store the data in a shared database, keep it in memory and have another WCF layer communicating between the two, etc. A shared database would be the most straightforward, especially if you want to persist the data for use by other apps/services as well.
WCF Service would be useful if you had one notification service on your server with multiple WPF client application connecting to it. If you have just one application running on the same server then not sure if it will be worth the overhead.
The usual pattern is to host WCF service in IIS, that way it always starts whenever first request is received. WCF is very flexible though, therefore you can host in in Windows Service, Console Application, etc.
I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!
I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service
You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking
Simple issue. I'm working on a proof-of-concept for an application with additional database connection, so I will create a WCF service to wrap around the database. Multi-user environments will get this service installed on a centralized server with a client application on their local system. These users will automatically have to deal with firewall issues, so this is acceptable.
But the single-user environments will have the service and client application running on a single system. The service host doesn't have a definite shape right now, but it's likely that it will be hosted within the application itself or as a Windows service.
Unfortunately, the client application is a WIN32 Delphi application which needs a simple way to access the service. Preferably, the single-user version should use the same technique to access the server as the multi-user version, which means that it behaves like a SOAP client, with a WSDL imported and converted to Delphi code.
Still not a problem, but I have to consider possible problems that we can encounter in this setup, with the most important issue: possible firewall that closed the connection port.
So, does anyone know about any firewall problems that can occur in this single-user environment?
You haven't mentioned which WCF channel you're using- I'll assume basicHttpBinding. Generally, if your local service is bound to 127.0.0.1 using self-hosting, and the on-box client accesses it that way, you should be fine. No firewalls I'm aware of will screw with your loopback adapter. If you bind the service to the machine's IP though, you may subject yourself to firewall fun.
If you have WCF 3.5 available on the client on both ends (sorry, I don't know anything about Delphi), have a go with netNamedPipeBinding.
You didn't mention which version of Delphi you use but I once had hard time making Delphi 2005 import a WCF service with basicHttpBinding. As the WSDL is split among many pages, the SOAP import wizard in Delphi wasn't capable of understanding it. I finally ended up writing an ASMX wrapper around the WCF service for Delphi clients.