Short Verstion: I have a task that I need to make an application get a computer's camera screenshots, and send to another computer running a Windows Service, in the same local network (but not connected to the internet), along with some other information.
Long Explanation: We have an application that runs in the background while the user takes a survey, and we get the user's information such as ID and we save his answers along with other information (only pictures at the moment).
We convert these pictures to data and send them to a WebService, which then saves in a server.
Now we're implementing an "offline" version of this functionality, and we're supposed to save the user's data to a specific computer in the local area network, running another application that saves these data to later upload them to the server when it's online.
Question What do I need on both PCs for this communication to work?
Is it possible to access the Windows Service in the Host PC if it doesn't have IIS installed? (It'll be a client machine so it probably won't have it).
I've been trying to google to understand what should I search/understand but I couldn't find anything that wasn't about WCF and IIS / Online services.
you need some form of communication between the 2. It could be TCP/IP sockets or WCF or classic webservices... but if it is webservices then you DO need it hosted in IIS just like WCF. But WCF allows you to not only host it in IIS but it can be self hosting in your application or you can also use the Windows Activation Services (WAS) too. TCP/IP sockets can also be a solution here. I would lean towards TCP/IP Sockets as the problem you describe is more suited for this than a full bloated service.
Related
I have several machines running an application that plays a video feed from a camera. Each machine is located behind a firewall on different LANs. I am trying to investigate an approach to be able to talk to these machines from an Azure web app and get access to the video they are streaming. I don't want to have to open ports on any LAN. My first attempt at this was to have a client running on each machine that contacts an intermediate Azure service via a TCP port, the port is kept open and the local machine sends data to the Azure service which basically downloads this data and then sends it on to any connected clients.
The problem I am having is the intermediate service essentially has to download each message and then retransmit it to any clients, I don't think this approach will scale as the intermediate server can become overrun very easily. Ideally all I would like the intermediate service to do is manage the connections between the local machines and the end client azure service so that they talk directly to one and other.
I guess this must be similar to what products like TeamViewer or LogMeIn do.
I'd appreciate any pointers or suggestions from others experience.
i'm writing a server side application and a windows service which need to be installed on a remote host
the service returns CPU usage to the serverside application - this is NOT the problem
the serverside application deploys the service on the remote host. - also, not the problem
THE PROBLEM:
but how do i setup a socket connection between the two, when i dont want to hardcode the ip address? (for scalability) - do i need to use multicast or is there some devious way of doing this? is there another solution than using sockets? -
i'm new to writing Windows Services.
I need help figuring out how to communicate between the server and the service without hardcoding IP-addr.
thank you in advance.
MY SOLUTION:
I created a windows service, that reads a xml file with the IP and port of the Server application. so when i deploy my client application, i also create a xml file with the network information.
Regards Alex
A lot of communication platforms now use network discovery; there's an article on codeproject that goes into detail about using network discovery.
The problem was, I did not know what machine name the server was running on, in fact I wanted this to be flexible, and selectable by the user.
Seems relevant to http://www.codeproject.com/Articles/16113/Retreiving-a-list-of-network-computer-names-using
Have you thought of using WCF?
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Regarding multicast, you can have a WCF server multicast announce it's availability on a network; see http://msdn.microsoft.com/en-us/library/dd456782.aspx
another solution could be to create the service as a console application with arguments (endpoint ip address) and then just deploy it with the arguments on the remote host
We are planning on implementing our new software application as shown below.
Does this architecture look fit for purpose?
Items to Note:
There are many PC's
The pc has a WCF client as it needs to upload data to the
database periodically.
The PC has a server because the end user on the terminal server needs
to be able to interrogate the pc for information
The terminal server is the GUI for users so they can remotely connect
to a specific PC to interrogate the pc for information
We are using basicHttpBinding below
What else have we considered?
We have tried WCF NetPeerTcpBinding (i.e P2P) but it does not support
request-reply operations.
We have tried WCF Duplex but with the requirements listed above in the items to note section we would end up with a client and server at both ends anyway.
Well I apologize but I basically disagree with your architecture.
WCF is not designed or suited for anything other than a request-response communication.
Its full duplex ability will not enable your server side to issue communication to a specific client unless that client already issued a connection to the server.
That means that in order to achieve a prestigious online full duplex communication with all your clients - all your clients must maintain an open port to the server.
Having a dual client and server per PC in order to achieve an online full duplex is a step forward as it will solve the issue of keeping a port open per client however it has downsides in terms of security as it means that the specific PC is open to receive multiple connection requests. Another issue can occur with deadly reentrancies if you not careful. So, basically you will be saving 'ports' in exchange for architecture
maintainability and fitness to your solution.
So if you are targeting a deployment of around 200-300 PC's your architecture will hold but if you are targeting a larger deployment of thousands of PC's - it will not hold.
I want to pass certain parameters to a desktop application remotely via the internet. I don't want my application to contact the server repeatedly, because many such applications can bring the server down easily. Is there a way to initiate the connection from the server? How can I identify the applications, as there will many of them running on many computers somewhere around the globe. I don't know where to start - I'm trying to do this in C# and ASP.NET/PHP on the server-side. Please give some advice.
Is there a way to initiate the connection from the server?
No. Not without having the client contact with the server first, informing it with the IP address, port to use etc... Which the server will need to keep for each client, hoping that they don't change (or get updated when they do change).
Long polling by the client is the right solution for what you are doing, even if you don't want to use it.
There are many different ways you could approach this, just thinking out of the box, both your app and the server could utilize a different mechanism for transferring the settings. I'm not recommending any of these methods, please don't shoot me down, they are all just ideas.
As an example, your server could connect out using FTP and output the updated settings to an FTP server on each PC. You could install something like Filezilla on each machine which runs your app. You'd obviously need to configure port forwarding on the router to allow the server FTP access.
You could use email. Setting up an email account where your server can login to send out the settings. Your app could possibly login to the same email account possibly even a single Gmail account to retrieve the settings.
Another idea would be to use a file sharing service like Dropbox, Google Drive or similar and where the settings could be shared. Obviously this would involve learning any API and I'm not sure if there are any restrictions on this approach.
The last idea and probably my preferred approach would be to host a web service and database on a remote server, both your server and the applications would connect to the same service to transfer the settings. This approach is obviously firewall/router friendly as all the clients connect out to the web service to collect the required data.
Hope this helps?
I need to write an application in C# that has to communicate with a service on a remote desktop. I would like to know if it will be better to write an application that sends information to a local service which in turn communicates with the remote service or would it be better for the application itself to communicate with the remote service directly?
Are there any advantages of using 1 method over the other?
EDIT:
The data is in the form of XML that is being passed to the service and there will be multiple instances of the objects in the application that will be sending and receiving information to and from the service.
Example:
Lets say that the application needs to retrieve a certain user's information from a DB. This DB is installed on another remote computer. There is a service on the remote computer that receives requests for information from the DB which it then retrieves, converts it to XML, and then forward this XML to the requesting application.
It's not entirely clear what you're asking. If this is specifically about communicating between your machine and a remote machine, whilst using Remote Desktop/Terminal Services, that you might be looking for Remote Desktop Services Virtual Channels.