I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.
I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html
Related
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?
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 would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
I have C# apps requesting data from PHP/MySQL API server (Rest/JSON). Now I also need to push messages to the C# apps when some events occur (form submission from the web site). I searched around, and it seems that COMET, long polling, and http streaming are options. Could you please provide some suggestions on which technology makes sense here, as I am not pushing to a web browser?
In addition, if using HTTP streaming (like twitter streaming API), do I need to keep a table of HTTP connections so I know which connection to use when pushing targeted events (only to certain C# clients)? I am a bit confused, and many thanks!
Make a WCF Web Service. http://www.codeproject.com/KB/WCF/WCFWebService.aspx
To connect using PHP: http://weblogs.asp.net/gunnarpeipman/archive/2007/09/17/using-wcf-services-with-php.aspx
In micro-services environment you might want to communicate between more different coding languages in the future, that's why in Kaltura we expose every API with descriptive XML that we can use later to generate client libraries in multiple coding languages, our code generator includes client libraries for C# and PHP.
I also published several REST server examples, including C#.
I've never had to do IPC on Windows before. I'm developing a pair of programs, a standard GUI/CLI app, and a windows service. The app has to tell the service what to do. So, assuming the communication is local only, what would be the best communication method for these two processes?
By best I mean more robust and less error prone, not the best performance nor the easiest to code.
Note I'm asking about what to use, a standard TCP socket, named pipes, or some other means of communication only.
IPC in .Net can be achieved using:
WCF
using named pipes requires .Net 3.0 and above.
Code example
The WCF class NetNamedPipeBinding can be used for interprocess communication on the same machine. The MSDN documentaion for this class includes a code sample covering this scenario http://msdn.microsoft.com/en-us/library/system.servicemodel.netnamedpipebinding.aspx
Remoting
The original IPC framework released with .Net 1.0. I believe remoting is no longer being actively developed, and you are encouraged to use WCF instead
Code example
Inter-process communication via Remoting - uses a tcp channel
Resources
GenuineChannels, sell a remoting toolkit that includes a Shared Memory Channel. http://www.genuinechannels.com/Index.aspx
Ingo Rammer, wrote the definitive .Net remoting book, Advanced .NET Remoting, Second Edition
Win32 RPC using csharptest-net RpcLibrary
I came across a project recently that has wrapped the Win32 RPC library and created a .net class library that can be used for local and remote RPC
Project home page: http://csharptest.net/projects/rpclibrary/
MSDN references:
How rpc works: http://technet.microsoft.com/en-us/library/cc738291(v=ws.10).aspx
RPC functions: http://msdn.microsoft.com/en-us/library/aa378623(v=VS.85).aspx
Also has a google protocol buffers rpc client that runs on top of the library: https://code.google.com/p/protobuf-csharp-rpc/
WM_COPYDATA
For completeness it's also possible to use the WIN32 method with the WM_COPYDATA message. I've used this method before in .Net 1.1 to create a single instance application opening multiple files from windows explorer.
Resources
MSDN - WM_COPYDATA
Code example
PInvoke.net declaration
Sockets
Using a custom protocol (harder)
For local only, we have had success using Named Pipes. Avoids the overhead of TCP, and is pretty much (at least for .NET) as efficient as you can get while also having a decent API to work with.
Since you are limited to .Net 2.0 WCF is perhaps not an option. You could use .Net remoting with shared memory as the underlying communication mechanism between app domains on the same machine. Using this approach you can easily put your processes on different machines and replace the shared memory protocol with a network protocol.
The standard method of communicating with a windows service is to use service control codes. Windows services can receive codes from 0 to 255. 0-127 is reserved for system. 128 to 255 can be used for custom commands.
If you need to send complex objects to the service use database, xml, file, tcp, http etc. Other than that for sending control commands like reload configuration, process items etc this control codes should be used.
There are additional functionalities available such as querying the service. See Windows service documentation and api.
http://arcanecode.com/2007/05/30/windows-services-in-c-sending-commands-to-your-windows-service-part-7/
Your best bet is to use WCF. You will be able to create a service host in the windows service and expose a well defined interface that the GUI application can consume. WCF will let you communicate via named pipes if you choose, or you can choose any other communication protocal like TCP, HTTP, etc. Using WCF you get great tool support and lots of available information.
I'd like to add to this discussion. Please rebuke me if this is way out there - but couldn't a semaphore (or multiple semaphores) be used for rudimentary communication?