WinForm and uwp how to communicate two-way, I used MQTT, the shortcoming is that when the amount of data sent is relatively large, there will be a very serious delay, but also try socket mode, but WinForm can not connect to uwp, which friend please help me, thank you!
From the document Note part, two independent uwp run on the same computer can not communicate by socket.
As a consequence of network isolation, Windows disallows establishing a socket connection (Sockets or WinSock) between two UWP apps running on the same machine; whether that's via the local loopback address (127.0.0.0), or by explicitly specifying the local IP address. More about UWP apps can communicate with one another, see App-to-app communication.
Besides, you can also integrate app services into your UWP app to allow the sharing of data and functionality across apps, see the topic Use app services and extensions.
Lastly, you can also refer this similar thread:
Communication between UWP and Non UWP app
UWP and WinForms should be able to communicate behind the scenes with standard C# constructs. I never used UWP, but in with WPF, WPF and WinForms more or less sit in the same process space. No need for fancy interprocess communication.
That said, perhaps you could give us an idea of what data is being passed?
EDIT: After some more info, I now understand you are talking about two different apps. In the past, WCF was the go-to mechanism for this, but I think there are better options these days. I yield the answer to someone more knowledgable
Related
What I want to implement is UWP-based programs and other C# programs are trying to communicate with Socket on one PC (Windows 10 Pro).
I have tried to make UDP communication module using DatagramSocket class and TCP communication module using StreamSocket class (https://msdn.microsoft.com/ko-kr/windows/uwp/networking/sockets) and it seems that module is not working properly.
In the Windows UWP example program and some developer forums, I saw a statement that it is impossible that socket communication between other programs on the same device.
I am wondering if it was the right I understood.
Also, if it is right, Would you recommend other ways to solve this problem?
I saw a statement that it is impossible that socket communication between other programs on the same device
It is right. According to the note of DatagramSocket official sample:
Network communications using an IP loopback address cannot normally be used for interprocess communication between a Universal Windows Platform (UWP) app and a different process (a different UWP app or a desktop app) because this is restricted by network isolation.
We cannot communicate a uwp app with other apps in a same machine.
Also, if it is right, Would you recommend other ways to solve this problem?
By testing on my side, if you use a c# console project as server and a uwp app as client, they can communicate successfully both with StreamSocket and DatagGramSocket. But following special steps need to pay attention to let it work.
Please ensure the Internet(Client&Server) and Private Internet(Client&Server) capabilities are enabled.
Run the server side as administrator.
Allow the network access promoted by windows when you run the server.
I wrote a demo which contains server side and client side of UDP and TCP. You can download here for testing.
And the results.
Although this can work, I recommend you to not use except for developing purpose.
I have been doing research for a few months now on the possibility of client-server communication. I have experimented with many methods such as WebORB and FluorineFX, which are both servers designed to deal with client/server authentication.
WebORB only runs on Windows for their .NET version as far as I can tell, and I would much rather use an open source system. I have tried using FluorineFX, but I think their must be a simpler way for me to build my own simple system from the ground up.
I have been using Dropbox for a while now, and I like the way that the client-server communication is instant. As far as I can tell (from some Google searches) the client doesn't open a port of its own, and just communicates with the Dropbox server through port 80. An example of its instant communication is where you may delete a file on Dropbox on their website, and instantly the server communicates with the client telling it what has happened. I don't know how this instant communication is possible without opening a port.
I can create a system that uses fetching from the client, asking the server every 10 seconds or so to see if there are any updates, but I would like a method to be able to push the information from the server to the client.
My server runs Linux so I don't think I can use WCF, and ideally I am looking for a way to make PHP and C# communicate with each other.
I would love to hear any advice that anyone has and how they deal with the problem.
Cheers.
You CAN use WCF to communicate with any platform. Just make sure you're using an endpoint which your target machine support: http://msdn.microsoft.com/en-us/library/ms733107.aspx
Have you tried the good old .NET Remoting which runs perfectly with Mono?
You can choose between a TcpChannel (for performance) and a HttpChannel (to pass proxy/firewall easily).
For push notifications, you can open a connection to your server and wait for an answer indefinitely.
I understand that trusted silverlight applications can communicate with each other over the LAN connection (peer to peer). Can they do this without an internet connection once installed out of browser? Do they need to first download some sort of Access Policy?
If not, is there some alternative way of doing this, perhaps with some kind of helper service on the computer?
Can they use similar techniques to talk to Local non-Silverlight devices, e.g. could a trusted silverlight application talk to an iPhone app over a local area network?
System.Net.Sockets.UdpAnySourceMulticastClient
Does allow you to connect between Multiple Silverlight applications on the same LAN. It does not require any internet connection after the application is installed out of browser.
I'm not clear if this could be used for communication with non-Silverlight applications althouh I believe it probably could since UDP Multicast is a standard protocol.
In situations where the network infrastructure is older it may not support UDP Multicast addresses. In this case, the best solution would be to install a separate local server on one of the client machines, to which all other silverlight applications could connect (once the user had typed in the IP address).
I'm not sure where you got your information from but as far as I'm aware there is no builtin way for Silverlight applications to connect to each other peer-to-peer. However it is possible to place a simple server application on the LAN through which Silverlight applications running on different nodes can communicate.
The plumbing needed to create peer-to-peer pipes is missing from Silverlight. It only has a means to connect to a specific TCP/IP port or to listen to Multicast UDP sources, it can't create a Listening port that waits for a connection nor generate UDP output.
You could go this by calling COM objects from Silverlight, however
Just because you can hammer in a nail
with a screw driver, does not make the
screw driver the best tool for the
job.
Have a look at using WPF so you get the full .net framework.
I want to create an application in Android which communicates with a server application (written in C#, doesn't matter what version of .NET) on the PC via TCP/IP.
What would be the best approach here?
I was thinking about some kind of RPC-like SOAP or XML-RPC. But I want to keep the server application as light and simple as possible. And I think in C# you rely on a Webserver to set up an RPC server. Is it better to communicate directly via the TcpListener?
I had pretty good luck using TCP/IP and UDP with android and windows (Java & C# respectively). I used a more brutal approach then the TCPListener for the C# but pretty similar at the high level. I would recommend giving it a shot and seeing the outcome, chances are it's going to be fairly more lightweight in terms of processing and bandwidth then an XML approach.
What kind of data will your program be sending over the network? If it's something simple why not use a high level protocol like http? I'm more of a java person, but I know that there must be a .net equivalent to running a lean http server to connect to.
We have a Java app, as well as a number of C#-based plugins for other apps (e.g. Excel) that can communicate with the main app. The communications layer is implemented using Apache MINA on the Java side and xsd for the .NET plugins. Typically things run on the same (Windows) machine, though it would be better not to assume that (e.g., allow the main app to run on a Mac and be able to communicate with Excel on a different machine).
The communication has to work regardless of whether the main app or the plugin(s) start up first. My question is how best to establish the link? Currently, our main Java app listens on a port that the plugins constantly poll for availability. This is obviously wasteful and inelegant. But it works.
An alternative would be to have each plugin listening on its own port, and when the app starts up it sends a "Hello" kind of message to each known port (on localhost), and then have the plugins establish the link at that point.
I've also looked a bit at multicast, but don't really know much about it. And of course, there could be multiple users on the same subnet all using the app.
Any other ideas or thoughts?
You should not be concerned with wasted attempts to connect to the server - it is not a resource intensive operation and the plugin requires the connection to work. There does not seems to be any real motivation to use anything different from a traditional client/server approach which you already are doing.