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.
Related
I have a C# program running on a local system that needs to be able to do two things.
Asynchronously spin off remote jobs on remote systems running Windows, Linux, or Android.
Provide a way for those systems to send back the output(StdOut/StdErr) of those jobs back to the local system.
Previously I have used WCF when communicating with a remote windows system. I created a WCF server on the remote windows system and then my local machine can send commands and messages via that WCF channel. Things get more complicated when I try to do the same thing with Linux and Android.
I figure I could setup a local WCF service using REST, that way all 3 platforms can send messages to it using whatever convenient language (Most likely c++) via JSON REST. But what then is the best way to accomplish requirement #1?
Should I bother creating a REST server in C++ that runs on Linux and Android?
Can WCF even consume a C++ REST server that isn't written in .Net?
Would I be better off doing something simple with just TCP sockets?
Security is not an issue since this is used on a secure private network. I'm just looking for the easiest way to run remote commands/processes and receive response messages from those remote systems.
I use ZMQ and JSON for exactly this purpose: creating a custom private network topology that communicates using JSON messages over TCP (via ZMQ). Of course you could use any serialization format (I list some alternatives below).
I can't give you a definitive "this is what you should do" answer, because the question is fairly open-ended.
ZMQ: http://www.zeromq.org/
Really nice cross-platform abstracted socket library
Can use various transport protocols, including TCP
Sends messages as just plain byte arrays, leaving choice of serialization format up to you
Some serialization formats (in order of my personal preference):
JSON: http://www.json.org/
MessagePack: http://msgpack.org/
Exactly like JSON, but much more compact
No schemas
Cross-platform
Google Protocol Buffers: https://code.google.com/p/protobuf/
Uses schemas
Has bindings for C++, C#, Java, Python (at least)
This can really depend on your infrastructure and services you are using. If you are in the Amazon Web Services world you could use a Simple Queue Service (SQS) to receive messages. The remote systems could then poll the queue and run the jobs based on the messages pulled off the SQS queue.
I have a server running on node.js, using socket.io and HTML5 clients.
I also have a more specific client written in C#, because it's running on Microsoft's PixelSense.
My primary idea was to use C# socket.io implementations, but i didn't found one of these working implementation :(
But, the good point is that the node.js is running on the pixelsense device. I can use more rustic solutions like file's pipes.
In your opinion, what is the best way to communicate between my node server and my C# client running on the same machine (windows) ?
Do you know a working implementation of socket.io in C# ? A small hack using files ? A use of a intermediate server ?
Performances and reactivity are a plus.
Thanks
What's the reason of socket.io usage? I think it's definitely better to use TCP Sockets for communication between this platforms. This way you can easy add SSL support and don't think about compatibility.
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.
Lets say I have my C# app installed on 2 laptops connected to a WiFi Wireless Local Area Network.
How can these apps send messages to each other? What method or library can I use? I heard of using sockets but I have no idea how to work with these.
You could use WCF to build a communication pipe between the 2 applications. WCF encapsulates the sockets into a more manageable interface. You can start here.
Basically, you'll want to do it the same way you would in any other language. You'll open a network connection of one flavor or another (raw TCP or UDP, or a higher level protocol like HTTP) with one side acting as a server and the other acting as a client. Then each side can write data through or read data sent by the other side. It's can get pretty complicated from there. If you Google "C# Sockets" or "C# HTTP", etc, you'll find quite a few tutorials on the subject.
This is a very good article on sending C# objects (which could include whatever messages that you want to send) over a Socket connection using the Binary Formatter. Although it is not the most efficient, it is quite easy to grasp and get working.
I would like to have a client-server application written in .NET which would do following:
server is running Linux
on the server there is SQL database (mySQL) containing document URLs
What we want:
- server side would regularly crawl all URLs and create a full text index for them
- client side would be able to perform a query into this index using GUI
The client application is written in .NET using C#. Besides of searching in documents it will be able to do a lot of other things which are not described here and which are done client-side very well.
We would like to use C# for the server side as well, but we have no experience in this area. How are things like this usually done?
Clarifying question now based on some answers:
The thing which is most unclear to me is how client-server communication is usually handled. Is client and server usually using sockets, caring about details like IP addresses, ports or NAT traversal? Or are there some common frameworks and patters, which would make this transparent, and make client-server messaging or procedure calling easy? Any examples or good starting points for this? Are there some common techniques how to handle the fact a single server is required to server multiple clients at the same time?
To use c# on Linux you will need to use Mono. This is an open source implementation of the CLR specification.
Next you need to decide on how to communicate between server and client, from the lowest level of just opening a TCP/IP socket and sending bits up and down, to .Net remoting, to WCF, to exposing webservices on the server. I do not know how compleat WCF implementation is on mono, also I think you may have issue with binary remoting between mono and MS .Net .
I would suggest RPC style WebServices offer a very good solution. WebServices also have the advantage of alowing clients from other platforms to connect easily.
EDIT
In response to the clarification of the question.
I would suggest using mono/ASP.NET/WebServices on the server, if you wish to use c# on both server and client.
One assumption I have made is that you can do a client pull model, where every message is initiated by the client. Using another approach could allow the server to push events to the client. Given the client has the ability to pole the server regularly I don't consider this much of a draw back but it may be depending on the type of application you are developing.
Mono allow execution of c# (compiled to IL) on a Linux box. Mono ASP.NET allows you to use the standard ASP.NET and integrate into Apache see http://www.mono-project.com/ASP.NET and finally WebServices allow you to communicate robustly in a strongly typed manner between you client and your server.
Using this approach negates most of the issues raised in your clarification and makes them someone else's problem.
Sockets/SSL - is taken care of by standard .Net runtime on the client and Apache on the server.
IPAddress/ports/NAT traversal - Is all taken care of. DNS look up will get the servers IP. Open socket will allow the server to respond through any firewall and NAT setup.
Multiple Clients - Apache is built to handle multiple clients processing at the same time as is ASP.NET, so you should not encounter any problems there.
As many have already mentioned there are a number of thing that you have mentioned which are going to cause you pain. I'm not going to go into those, instead I will answer your original question about communication.
The current popular choice in this kind of communication is web services. These allow you to make remote calls using the HTTP protocol, and encoding the requests and responses in XML. While this method has its critics I have found it incredibly simple to get up and running, and works fine for nearly all applications.
The .NET framework has built in support for web services which can definitely be called by your client. A brief look at the mono website indicates that it has support for web services also, so writing your server in C# and running it under mono should be fine. Googling for "C# Web Service Tutorial" shows many sites which have information about how to get started, here is a random pick from those results:
http://www.codeguru.com/Csharp/Csharp/cs_webservices/tutorials/article.php/c5477
have a look at Grasshopper:
"With Grasshopper, you can use your favorite development environment from Microsoft® to deploy applications on Java-enabled platforms such as Linux"
Or see here
The ideea is to convert your app to Java and then run it on Tomcat or JBoss.
Another approach: use the Mod_AspDotNet module for Apache, as described here.
This Basic Client/Server Chat Application in C# looks like a kind of example which might be a starting point for me. Relevant .NET classes are TcpClient and TcpListener