I'm working on a project where a program running on the mobile phone needs to communicate with a program running on the PC it's connected to. Ideally, I'd like to use USB, WiFi, whatever to communicate.
The two programs should be able to communicate things like battery life, text messages, etc... But I can work on that later, I just need to get them to talk.
What's the best way to do this?
Assuming you have a wifi connection, one way for your Windows Mobile program to communicate with your PC would be to use WCF on the .NET compact framework 3.5.
You'd create a new WCF application to run you your PC, and expose an interface exposing functions you want to call from your Windows Mobile Device.
WCF on Windows Mobile requires Compact Framework 3.5 to be installed on your device.
You also need the "Windows Mobile power toys" to be able to generate compatible proxies to call from Windows mobile.
Power Toys for .NET Compact Framework 3.5
Calling the WCF service from your WM Device also requires you to manually set up the binding and endpoint to pass into your web service proxy (with desktop WCF this is done automatically by loading them from a config file).
WCF on Windows Mobile currently only supports the basic http binding (which can be encrypted if you want), but this may be enough for your needs.
"Best" is really subjective and highly dependent on a lot of factors like devices, topology, firewall presence, need for security, etc, etc.
Where do you need the comms to originate and will you have an ActiveSync connection? If the PC initiates the comms and you have ActiveSync, then RAPI is the transport you'd use as it's got all of the infrastructure done and ready.
For anything else you're going to need some form of proprietary protocol and transport mechanism. Typically I write a simple socket protocol with a defined message structure (typically a message ID, CRC, message length and data payload). I then have some base message class that handles the comms and a set of derived messages for each specific command I want. For 2-way stuff that requires a response, I typically create a base Response class and then derive specific response formats from it.
You might try looking into the OpeNETCF.Desktop.Communications library. You can start at http://www.opennetcf.com/FreeSoftware/tabid/84/Default.aspx and follow the links to find the necessary downloads. (I think you may need to get it from their subversion repository).
WIMO is working on WiFi to desktop support and may be done. Might be worth a look at the code either way.
home
source
found this in 2015, so I don't think the answer is going to be relevant for the original asker, but for the record:
Proximity
https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh465205.aspx
Related
I'm wondering if anyone has any recommendations for the best way to implement a command line interface to an existing Windows service.
Ideally, the following requirements can be met:
Supports .Net Core and works cross platform
Is self hosted (ie not a separate executable)
Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)
Can be piped through to a web interface for remote terminal access via existing web app
Is available via terminals on other local network devices
The big requirement is that this works cross platform and is not tied to Windows. Any recommendations are very much appreciated!!!
Questions that feature the phrase "what is the best" typically aren't a good fit for stackoverflow as they're subjective - there may be no right answer to your query, but maybe there will be some good ones.
One option that I've employed several times in the past is to implement something like a simple shell/command prompt, accessed via telnet. You simply open a listening socket (TcpListener) and accept text commands sent to it/write text to it, something like your first day's of programming, with console in and out stream printing. There are bucketloads of examples on the web of simple tcp servers so I won't provide any code here. In terms of your points:
Supports .Net Core and works cross platform
It's tcp based, this is intrinsic
Is self hosted (ie not a separate executable)
Starts when the app starts, hosted by the app, doesn't need any complex IPc
Is registered globally and available in any terminal (ie. > myApp doThis -please --prettyplease)
The firewall is probably the only thing stopping your remote device communicating
Call be piped through to a web interface for remote terminal access via existing web app
html5/web based implementations of telnet exist. Could also make a simple web interface out of it (treat the browser like telnet; Here's little difference between them, they both read and write tcp sockets, just the browser adds more text from the http protocol. You can filter that out and just get the interesting bit the user can vary (the URL))
Is available via terminals on other local network devices
Covered above
The last time I implemented this was on a server that was used by credit card terminals. It already had a listening socket and clients followed a strict protocol, so it was easy to detect when a message didn't match protocol and treat it as a command instead. The system grew to the point where the server was full remotely configurable via a simple telnet interface, new credit card ranges and routings could be added,debug printouts could be enabled and all traffic would be sent to the telnet client, certain card terminals could be monitored etc; it was nothin more than compsci101 stuff of command = streamreader.ReadLine(), if(command == "debug") Global.DebugLoggingStream = tcpWriterStream
It had a web interface too, based on HttpListener, that just provided a nicely formatted list of the most recent errors, some config settings etc.. some stuff is better on a web page in a table than in an 80char column format. Eventually I upgraded this to be more like the terminal; the user could end the URL with a command, the command would be carried out and the result put in an array. Each time the page was served he array was dumped, so it became a sort of command shell in itself, not requiring telnet. I kept the telnet interface because it was good for realtime debugging, watching messages as they happened etc but if you wanted to get really fancy, websockets exists today for that sort of thing.
Another thought struck me; perhaps most of this hard work has been done for you, if you can find a c# implementation of an irc server, paired with a web based irc client, it would provide a way to "chat" with your service (which is pretty much all a command shell is; a human having a text chat with a program)
Is it possible to implement client/server communication between a C++ program (client program) running in linux OS with a C# program(server program) running in Windows using RMI implementation?Can anyone suggest any possible way...Any kind of helpful reference is welcome
You would need to go along the lines of Google Protobuf. It is available with C++ and C# as well.
A similar answer from MSDN
It does not matter if you send data from java,c++ or c#, when it goes
over the network it's just 1s and 0s. It's a matter of what you do
with it on the client/server side. So, be sure that the data that you
receive corresponds with the structure that you have (that you want to
deserialize to).
Sometimes you need to manually put the bits and bytes together to get
it all working out. However, there is something called "Protobuff"
that can help you get a common structure of the data that you send,
google it and read all about it.
You can implement client server with sockets and serialize/deserialize it using protobuf.
(MSDN link might help in solution)
I think message passing libraries would fit best in to this. Take a look at ZMQ for instance; they have binding for many languages found here
so you may have your event dispatcher in one language and listener in the other language. Also take a look at apache thrift
CORBA is one IPC mechanism that will provide the RPC mechanism that you are looking for.
Here is a link describing communication between C# server and JAVA client.
http://iiop-net.sourceforge.net/dnAdderRmiClient.html
At one of the companies I worked previously, it was used for communication between c++ and java programs in a client/server model.
They used a combination of ACE/TAO libraries.
http://www.cs.wustl.edu/~schmidt/TAO.html
I would recommend that you do not use remote method invocation for communication between a client and a server. In the nineteen-nineties we used to believe that RMI is a good idea, but since then we have realized that there are much better ways for communication between computers.
The most popular way is by using Web Services, and the easiest flavor of Web Services is RESTful Web Services. (Look them up.) This has the benefit of not caring at all whether the runtime environment of the client looks anything like the runtime environment of the server, as the case is with your setup, where your client is C++ on Linux and your server is C# on Windows.
Mozilla's XPCOM might be your bridge. There is also PyXPCOM. Realistically though the easiest way is to have an intermediate VBox. So you run a VBox instance (running Windows) on the linux machine and then use VBox API (from C++) to issue commands within VBox. So you end up with
Linux <--xpCom--> VBox <--COM--> Windows
When working over network it's protocol what matters, not the client/server.
In telecommunications, a communications protocol is a system of rules that allow two or more entities of a communications system to transmit information via any kind of variation of a physical quantity. These are the rules or standard that defines the syntax, semantics and synchronization of communication and possible error recovery methods.
Source Emphasis is mine.
So, in order to communicate your C++ client and C# server you need to choose or define protocol that will be used for communication.
Your protocol can be build above another protocol. For example, you can use HTTP for transportation purposes and define your protocol describing what syntax should be used for messages in HTTP requests and responses bodies. This will help you, because there're many ready-to-use solutions for HTTP communication.
Actually you will build your protocol based on another anyway. HTTP itself build above TCP. You'll need to choose whether it would be low level or high level protocols. They all have their pros and cons.
But you will have to deal with messaging between your client and server yourself.
As an alternative you can use some Remote Procedure Call(or RPC) solution:
Remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.
So that means that you only have to follow guidelines how to build your client and server and all communication will be hidden and will look like as just calling object's method.
Source
Here's short list of possible RPC solutions:
Component Object Model with DCOM. Wiki: COM,DCOM. MSDN: COM, DCOM.
Simple Object Access Protocol. Wiki.
Windows Communication Foundation. Wiki. MSDN. SO(credits to Sanju for link).
To wrap it up:
It's not a problem that your client and server are in different environments and are developed using different platforms. You only have to build communications between them using either your own messaging system based on some protocol, or some RPC system.
We could just write a C# program to listen messages from a particular port and write another C++ client program to write message to that port.As thus we could communicate both application.
I should make an application for Windows Phone 7.5, which is able to communicate bidirectionally with the same application installed on other devices with the same operating system.
I read that the Silverlight version on Windows Phone only supports BasicHttpBinding, so I think I will have to implement bi-directional mode using the BasicHttpBinding: for example, the node that accepts the incoming "connection" could send a GUID to the requesting node in order to identify a kind of session (this GUID should then be sent for each subsequent communication between two nodes).
Are there better alternatives?
The core of all communication is communication between two nodes:
there are three types of requests (one of these must be very frequently, say every 10 seconds);
the node which receives a request, could answer or ignore the request.
What is the impact on performance?
I don't think there is a way to accept connections on WP7 devices, see here.
Since WP7 doesn't support poll duplex WCF services either, I recommend you manually implement it, similar to this: http://www.dominikschmidt.net/2010/12/windows-phone-7-callbacks-and-duplex-wcf/
You will need a central server which all clients continually post messages to. Every time a Client1 calls the server, it checks the database to see if Client2 sent Client1 a message. If so, that message is included in the response to Client1.
You probably need a relay service since it's unlikely you're going to have routable, stable communication directly between devices. For example the Project Hawaii Relay Service likely will provide what you want, or you could implement something that looks and acts a whole lot like it on your own server.
The requirement:
My [windows/web] service in C# 3.5 periodically has something to say about its state. It could be a progress status, log entry, error or warning, or signal of data availability.
Client applications are on the same network, and they would like to learn about some of these messages.
Clients start and stop randomly, largely outside of my control.
Clients are written in C#, C++ and even Delphi.
Database connection that can support storing my service's messages may not be available.
I would like my service to publish its messages (text-based protocol) for subscribers to be able to see and react to. I don't want to bother with how many clients are connected, or are there clients at all.
I was looking into named pipes, regular TCP/IP, semaphores, but I cannot seem to find anything that fits the bill.
Currently I'm forced to store a file on the network that is being currently updated, but it's not clean, and requires clients to have access to a network share.
Looks like you need to use WCF for this.
WCF can handle named pipes, TCP/IP and it can do windows and Web services.
You can have a look here:
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Hope this helps!
Check out the OWIN project and the Kayak implementation.
It will allow you to run your own in-process web server.
I am using WCF to write a server that should be able to communicate with .Net clients, Android clients and possibly other types of clients.
The main type of client is a desktop application that will be written in .Net. This client will usually be on the same intranet as the server. It will make an initial call to the server to get the current state of the system and will then receive updates from the server whenever a value changes. These updates are frequent, perhaps once a second.
The Android clients will connect over the Internet. This client is also interested in updates, but it is not as critical as for the desktop client so a (less frequent) polling scenario might be acceptable.
All clients will have to login to use the services, and when connecting over the Internet the connection should be secure.
I am familiar with WCF but I am not sure what bindings are most appropriate for the scenario and what security solution to use. Also, I have not used Android, but I would like to make it as simple as possible for the person implementing the Android client to consume my services. So, what is my strategy?
with the small bit of android I have done.
the android sdk doesn't natively support soap server, you have to write it all your self.
Rest is your only option when working with WCF and android. Thats the way that Google are pushing you to develop apps.
WCF via HTTP transport is the way to go because it is not binary and does not make assumptions re all peers are .net/windows.
see this page for more info