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.
Related
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.
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.
In an Azure-based web application, I want a client to be able to send a TCP packet to port 293 on my server and, in response, my web app should open up a socket for the client (and be able to send TCP back).
Does it work the same in Azure as it does in any C# server? Does the socket C# file go inside a web role or worker role? What classes can/should I use?
All help is appreciated!
Web Roles and Worker Roles are essentially Windows Server 2008 SP2/R2 with and without IIS running, respectively. As for code, do whatever you'd do in Windows Server to listen on a particular port.
A port maps to a specific role. So, if you have a Web role and create an input endpoint on port 293, then that traffic would be directed to your Web Role (and load-balanced across all instances). Likewise, if you set up the port on a Worker Role, the traffic would go to instances of the Worker Role.
If your socket listener is actually going to save data that's being uploaded, you need to make sure your saved data goes to durable storage - that is, to Windows Azure blobs or tables, or SQL Azure. If you write to a local disk (including disk local disk space allocated as a Local Resource), it's non-durable and you cannot count on data sticking around if something goes wrong (e.g. disk failure).
I have a device connected to a host computer through cradle usb. Now, I'm just wondering if I could use C# sockets to communicate with the device (ie device sending data, host computer processing it then replying back to the device). How can I accomplish this? by that, what ip address etc etc.. do I have to change so that it would connect cause I have the sockets working on wireless. If not, then is there a way to connect to the device, open and read a file (a text document to be more specific) from the device to my host application.. any ideas?
Thanks! :)
Depending on your target device, when you connect via ActiveSync it likely makes a local RNDIS network connection between teh two devices. You can resolve "ppp_peer" as the partner's network name instead of trying to use a hard-coded IP address (IIRC the IP is different on XP than on Vista).
Be aware that it's not a full connection. TCP packets gets passed through, but things like ICMP do not.
Of course, this just gives you a socket connection, just like if you were to connect between two PCs. It's not going to allow you to do file system operations unless you have an app on the other side listening for commands. If you want that type of thing, Microsoft provides the Remote API (RAPI) interface (wrapped in managed code here)for a lot of basic commands, and it can be extended (with C) to do anything you'd like.