I want to implement a adapter which can provide a universal interface to clients to use socket, opc, message queue, etc. In other words, it is a non-trivial job to learn to use the three above protocols' api.
For example, the client want to communicate with a external socket server, and the only thing he should do is to use our simple api rather than the complex bsd-socket's.
I want to know is there any existing implementation now which I can learn from. thanks!
ZeroMQ provides a socket like API that allows you to abstract away the transport mechanism. Currently it supports in process, shared memory, PGM, and TCP as transport mechanisms.
Google has protobuf, i think it's called, and there is another i've seen mentioned but it escapes me at the moment. Check here for information on protobuf
Related
I'm writing C++ applicatoin which needs to receive notifications for data changes from PostgreSQL through libpqxx library. But it's tutorial doesn't include such use case. The notifications must be received on multiple channels. Also I'm using boost::asio as networking library and for me is preferable if possible to use asio socket classes with asynchronous callbacks for notification events instead of polling of raw BSD style sockets. Can someone provide sample code for this or links to some external resources for how this can be achieved?
You need a class derived from pqxx::notification_receiver, see http://pqxx.org/devprojects/libpqxx/doc/4.0/html/Reference/a00208.html "Notifications and Receivers" and
http://pqxx.org/devprojects/libpqxx/doc/4.0/html/Reference/a00062.html which is the API reference for notification_receiver.
I have a C++ application that needs to send structured data to an Akka actor. The best option I found (Google, stackoverflow...) is to use protocol buffer and ZeroMQ, since it looks like everyone recommends it.
However I struggled the whole day trying to make it work, having various crashes into my Scala actor code (with strange Windows socket errors). And when I take a deeper look at it, I notice that it seems zeromq disappeared from the Akka official documentation a while ago, and the most recent documentation I read about it said that ZeroMQ 3 was still not supported by zeromq-scala-bindings underneath (while the version 4 is already out).
Would it be a better option to use the Camel-netty extension and pass the information through JSON ?
Thanks !
A fairly simple way would be to write a HTTP endpoint using Spray.io. Spray has JSON support and since it is built on Akka it communicates seamlessly with other Actors. This has the advantage that the data you send to the endpoint does not have to match the message format the Actor is expecting. You can change the message the actor is expecting without changing what your C++ code sends. For bi-directional communication there is also web socket support.
I am developing a client/server application for which I am evaluating a few options for the communications layer.
As part of this communication framework, I am contemplating using google's protocol buffer (PB) for representation of the transport data instead of re-inventing my own binary structure.
Now coming on to the actual transport, I am wondering if one should use plain sockets to send/receive these binary messages or use some form of middleware. Using a middleware has certain obvious advantages over sockets. A few that I care about include: communication models - publish/subscribe, request/response and fail over.
On the other hand, using sockets has the advantage of low overhead compared to the middleware approach and will deliver better performance.
One can also think of using the RPC libraries available with protocol buffers (third party add-ons on google's protocol buffer wiki) to communicate between the client and the server. Though it abstracts from the low level socket, it still does not support the middleware features.
At the moment, my client is an Adobe Flex GUI and two server side processes (One java and another C++). In the future, the client and server side can potentially have other services developed in other languages as well such as .NET
What do the experts feel about these choices and from experience what works well without compromising on performance. Are there other alternatives that developers go with?
Thanks
Dece
Unless it's a learning exercise, you absolutely, positively must use some middleware. There are lots of choices: AMQP, ZeroMQ, XMPP, Comet/Bayeux.
For your scenario, you probably want something web-based, so XMPP over HTTP may be a good option. However, I'm partial to Comet (though I have found Bayeux to be too complex for my needs).
Which platform?
If Windows then I have a free, simple, high performance, IO completion based pluggable server platform called WASP which is available from here.
Simply write a DLL or two and plug them in and you're done with the networking.
I don't currently have a protocol buffers based plugin example but it's on my list of things to do...
I would like to create a connection between two applications. Should I be using Client-Server or is there another way of efficiently communicating between one another? Is there any premade C++ networking client server libraries which are easy to use/reuse and implement?
Application #1 <---> (Client) <---> (Server) <---> Application #2
Thanks!
Client / server is a generic architecture pattern (much like factory, delegation, inheritance, bridge are design patterns). What you probably want is a library to eliminate the tedium of packing and unpacking your data in a format that can be sent over the wire. I strongly recommend you take a look at the protocol buffers library, which is used extensively at Google and released as open source. It will automatically encode / decode data, and it makes it possible for programs written in different languages to send and receive messages of the same type with all the dirty work done for you automatically. Protobuf only deals with encoding, not actually sending and receiving. For that, you can use primitive sockets (strongly recommend against that) or the Boost.Asio asynchronous I/O library.
I should add that you seem to be confused about the meaning of client and server, since in your diagram you have the application talking to a client which talks to a server which talks to another application. This is wrong. Your application is the client (or the server). Client / server is simply a role that your application takes on during the communication. An application is considered to be a client when it initiates a connection or a request, while an application is considered to be a server when it waits for and processes incoming requests. Client / server are simply terms to describe application behavior.
If you know the applications will be running on the same machine, you can use sockets, message queues, pipes, or shared memory. Which option you choose depends on a lot of factors.
There is a ton of example code for any of these strategies as well as libraries that will abstract away a lot of the details.
If they are running on different machines, you will want to communicate through sockets.
There's a tutorial here, with decent code samples.
My company is planning on implementing a remote programming tool to configure embedded devices in the field. I assumed that these devices would have an HTTP client on them, and planned to implement some REST services for them to access. Unfortunately, I found out that they have a TCP stack but no HTTP client. One of my co-workers suggested that we try to send “soap packets” over port 80 without an HTTP client. The devices also don’t have any SOAP client. Is this possible? Would there be implications if there was a web server running on the network the devices are connected to? I’d appreciate any advice or best practices on how to implement something like this.
If your servers are serving simple files, the embedded devices really only need to send an HTTP GET request (possibly with a little extra data identifying the device, so the server can know which firmware version to send).
From there, it's pretty much a simple matter of reading the raw data coming in on the embedded device's socket -- you might need to only disregard the HTTP header on the response, or you could possibly configure your server to not send it for those requests.
you don't really need an HTTP client per-se. HTTP is a very simple text-based protocol that you can implement yourself if you need to.
That said, you probably won't need to implement it yourself. If they have a TCP stack and a standard sockets library, you can probably find a simple C library (such as this one) that wraps up HTTP or SOAP functionality for you. You could then just build that library into your application.
Basic HTTP is not a particularly difficult protocol to implement by hand. It's a text and line based protocol, save for the payload, and the servers work quite well with "primitive, ham fisted" clients, which is all a simple client needs to be.
If you can use just a subset, likely, then simply write it and be done.
You can implement a trivial http client over sockets (here is an example of how to do it in ruby: http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm )
It probably depends what technology you have available on your embedded devices - if you can easily consume JSON or XML then a webservice approach using the above may work for you.