I want one application on a linux host to call procedures from applications on Win7x64 in a VM. I guess that the VM runs on the linux host does not matter since it should use sockets. How do approach this plan? Are there any libraries for that in the internet?
Edit:
Well I took am look at all of them. XMLRPC seems to be some kind of predecessor of SOAP. Prototbuf seem to me like having the focus on easy serialization of large objects. So my decision falls on SOAP. But now I am searching for a nice-to-use c++ binding. I read a few pages of the apache axis2 manual but its everything else but nice-to-use, and anyway in C.
Another question in my specific case is: Isn't it easier to send just send some textual numbers plus parameters to identify the procedures to call and reply in textual form, as I know the signature of the called procedures?
Edit2:
As SOAP is just a standard and RPC is just curious, (Imagined something like function pointers over IP :D) ,imho none of them all is a solution. But ZeroMQ is indeed a progress.
There is no magic to RPC. I would suggest having a look at a combination of ZeroMQ and Google protobuf. ZeroMQ is a very easy to use messaging system (your communication layer). You would use the REQ/REP pattern. Google protobuf is used to describe and serialize/deserialize your messages. Both libraries are cross-platform and even cross language (ruby, python, c++, etc. etc.)
Have you taken a look at SOAP? It has pros and cons but may meet your needs.
The fact that your Windows box is VM shouldn't make a difference providing that it's up and running, and so long as the system you choose treats the servers as logically separate sockets normally would, your solution will remain flexible.
One decent alternative is XMLRPC, which runs on top of HTTP. It's simpler than SOAP, at least. I've used it for Java-Python communication, and it was not much code then, but don't know any C++ libraries to recommend, so I'll just say http://en.wikipedia.org/wiki/XML-RPC and its C++ section to that.
Edit after edited question: For a really simple solution, just use plain HTTP, mapping request path to function and giving parameters with GET or POST. Return value in HTTP response data as simply as you can: plain text for number or string, for more complex return value a binary blob if binary compatibility can be ensured (same CPU, same word size, plain struct, using compiler struct packing options if needed), or as json (or even XML, but then you are starting to reinvent SOAP/XMLRPC...).
Related
There are various exchange languages - json, ect - that provide an ability to quickly and reliably export and parse data to a common format. This is a boon between languages, and for it there is Piqi, which basically generates parsable exchange formats for any type that you define; it automates the process of writing boiler code (writing functions that read in some exchange info and build up a instance of some arbitrary type). Basically, the best option to date is protocol buffers, and I absolutely want, if I go down the route of ocaml-rpc, to use protocol buffers.
It would be nice if there were some declarative pattern to manage function exposure, so that the ocaml library can be reached over some medium (like RPC, or map a function to a url with encoding for arguments).
Imagine offering a library as a service; where you don't want to or can't make actual bindings between every single pair of languages. But servers and the data parsing has already been written... so wouldn't there be some way to integrate the two, and just specify what functions should be exposed and where/how?
Lastly, it appears to me that protocol buffers is a mechanism by which you can encode/decode data quickly, but not a transport mechanism... is there some kind of ocaml-RPC spec or some ocaml RPC library? Aren't there various RPC protocols (and ergo, if I try to point two languages using diff protocols at one another, achieve failure)? Additionally, the server mechanism that waits and receives RPC calls is (possibly) another module(?)
How do I achieve this?
To update this, the latest efforts under the piqi project are aimed at producing a working OCaml RPC service. From this, it would be, in vision, easy to specify what functions to expose at the RPC service end, and target function selection on the client side should allow for some mechanized facility to allow those exposed functions to be selected.
At the current time, this RPC system for ocaml facilitates inter-language exchange of data that can be reconstructed by parsers through the use of proto-buffers; it is under development and still being discussed here
I think that ocaml-rpc library suits your requirements. It can infer serialization functions and, also, can generate client and server code. The interesting part, is that they use OCaml as a IDL language. For example, this is a definition of the rpc function:
external rpc2 : ?opt:string -> variant -> unit = ""
From which there will be inferred server and client functorized code, that will take care on transporting marshaling and demarshaling the data, so that you need to work only with pure OCaml data types.
The problem with this library is that it is barely documented, so you may find it hard to use.
Also, as now I know, that you're tackling with BAP, I would like to bring your attention to a new BAP 1.x, that will be ready soon, and it will have bindings, that will allow to call it from any language, although currently we're mostly targeting python.
I'm writing a distributed system wherein each node interfaces with local applications via some RESTful API, supports extensions and runtime customization, etc. It's a bit like an Enterprise Service Bus over the wide area, but with a lot else going on which is not related to the question at hand.
I've read a little about both MPI and Asio - originally I was set on Asio, but then I found MPI, and now again I'm thinking Asio is the better solution for me. MPI seems to provide a lot I don't need and a higher level of abstraction than I want - for example, I only need point-to-point communication, and it is important to me to be in control of when and what data is transmitted. (e.g. I have already designed a packet structure that I would conform to ideally)
So my primary question: it is worth it to start from a lower level with Asio, or should I try to graft MPI onto what i'm looking for? Further, are there 'skeleton applications' available which use MPI or Asio which would aid development? (Actually I am 100% new to C++.. ;) Or, does it make sense to use them in tandem?
For more perspective, maybe it's worth noting that I already have implemented the bulk of this project in Perl using Perl Object Environment, which itself is just an asynchronous event system with a ton of networking libraries.
Also, if it makes a difference, I would ideally use threads for this.
Honestly though I have not used Boost at all yet, as I hinted above, so any input is appreciated.
I should start by saying that I know nothing about Asio, but from the 2 minute scan of the website and the description of your problem, it sounds like while either would probably work for you, Asio might be simpler. MPI is really designed less for general purpose network communication and more for running applications where the set of processes and applications is a little more static. While it provides a client/server style interface if desired, it's not the main focus of the library.
MPI is also more difficult to use if you already have a packet structure designed. MPI is great for abstracting away the need to worry about packets, location of processes, etc. but if you've already taken all of that into account in you application, you have already done the hard work.
There have been at least one other discussion of Asio vs. MPI that you can take a look at (For distributed applications, which to use, ASIO vs. MPI?) to get more opinions too.
I want to stream some data from my program for other subscribers (other programs). These programs can use these data as streaming event.
What I want?
How it is done generally?
Any libraries or papers pointing to technique and pros/cons?
Security related Ideas?
I will dig more information on my own even if I get a small hint.
Example :
Program A : Object A changed =======> Program B : Report Change in Object A
Two things are generally used: sockets/pipes which are just your basic byte streams, and message passing which is a bit more complex, made for parallel use and horizontal scalability.
I am not sure if it is a bit advanced, but have a look at boost::asio
http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/overview/core/basics.html
Best I found:
Google Protobuf
Facebook Thrift
Pros:
Helps with establishing the formats for streaming
Fast
Easy to build
Cons:
List item
Other top-level design issues (bandwidth control, cancelation) have to go on top.
Broadly it sounds like you're trying to perform inter-process communication, aka IPC.
In the tags to your question you refer to Windows. This link provides a broad list of the IPC options within Windows.
The tag list for your question also says platform-independent. Either a socket based solution or a Pipe based solution will mostly standard across a large number of platforms that you're likely to develop for. You can either use sockets directly or use one of the numerous cross-platform wrappers, eg. ZeroMQ and Boost, to hide some of the detail.
It's not clear from the question whether Program A and Program B are running on the same machine? If not then using sockets is a better approach.
I am looking for an HTTP library for C/C++, that handles only the protocol logic, instead of the actual transport mechanism. Libraries I've came across tend to incoperate the entire communication process, which is not what I need.
However, I'm looking for something that's more than merely an HTTP parser. Ideally it would also take care of things such as session/connection management, multiplexing, etc... only that it would leave the actual implementation of the communication details for application to perform. I'm looking at both client and server ends, though any of them would be helpful.
Preferably I'm looking for something that's free (non GPLed, though). HTTPS is a plus. Lightweightness is a plus. Simplicity is a big plus.
Anything like this?
I think the best thing you are going to find is one that implements it in a well separated manner. An HTML Server without a socket implementation is useless to most of the world. I would look for well separated code. Here is an example of a very minimalistic html server that seems it may be well separated, not completely sure, as I have not tried it myself, but you could replace the socket classes with your own implementation and wrappers, and do it that way.
http://www.adp-gmbh.ch/win/misc/webserver.html
There may be other examples out there as well. A good google search may be your friend here. At any rate, I don't think you are going to find a totally disconnected server and client that is totally abstracted from the socket implementation(s) that they use. I've had to do this myself before, to write an html client that did not use sockets, but used serial io to another device, that would pass the data through onto the wider internet.
The problem is that once you want it to do session management, it's a LOT simpler to write the library to include the transport (usually sockets) handling directly, rather than try to define a usable interface that the application can implement to do the underlying transport work. Especially since most (obviously not all) users need both components anyway.
If you want a subset of a web-server read the source-code of an open-source server and strip out what you don't need. You might want to look at lighttpd and nginx. They are simple lightweight web-servers.
libsoup seems to do what you described. neon is close.
session/connection management
libsoup: soup_session_sync_new()
neon: ne_session_create()
multiplexing
I'm not sure what exactly you mean. whould you mind to enlighten me?
leave the actual implementation of the communication details for application to perform.
libsoup: soup_message_headers_foreach() and soup_message_body_flatten()
neon: no public API (would be nice to have build_request() as public)
both client and server ends
libsoup: client and server API
neon: client only
free (non GPLed, though)
libsoup: LGPL
neon: GPL
HTTPS
libsoup: yes
neon: yes
Lightweightness is a plus
it depends
Simplicity is a big plus.
it depends
Is it possible to exchange web-services over socket programs written in C/C++?
The data to exchange are in the from of xml/soap message.
Yes, it is possible. You can write code that uses standard POSIX sockets, so it will be portable between windows and unix-like operating systems. But you'll very likely want to build up some layers of abstraction to make it all easier on yourself, or use an existing library.
As for talking to webservices, you will need some sort of XML/Json/whatever parser. SAX is a good XML parser, and I'm pretty sure there is a C interface for that. But it all depends on the data format.
http://www.securitytube.net/Socket-Programming-Basics-Presentation-video.aspx
If you're using web services, you'll spend more time writing socket code than you will writing code to consume the web services.
If it is SOAP web services, use gSoap (http://www.cs.fsu.edu/~engelen/soap.html). If it is something like REST web services or plain data exchange over an HTTP post without all the SOAP protocol stuff, libcurl (http://curl.haxx.se/) is easy to use too.
Both libraries will work on Windows and Linux.
Put simply, yes. I suppose you likely want more detail than just a "yes", but the question is far too general to garner any much more specific answer.
You mention UDP and even raw sockets, but it's not clear to me why. "Web Services" are typically HTTP, which means they're over TCP.
I think at this point in your learning there are just far too many things for you to learn that it sounds like maybe you just don't even know the questions to ask. Perhaps if you could be more specific about what you're trying to accomplish folks could provide more helpful answers.
Maybe you want to try CGI? With it it's possible to create a website in C++, without worrying about sockets.. Your compiled executable will be executed by the web server every time a page is requested, and the output of said executable will be sent to the web browsers.
So you can do stuff like cout << "<html>";.
[I know that this is not exactly what you asked but your question isn't very clear, and I didn't want to repeat something already said!]