I'd like to implement a communication link between an Apache-hosted webpage and my custom C++ app running on a small Linux device such as a Raspberry Pi or a DD-Wrt.
There's a tutorial here for the Raspberry Pi that uses buttons on a webpage to control LEDs on GPIO pins. The example uses MySQL as a communication interface between the webpage and a script and the script has read/write access to GPIO. Although MySQL offers the advantage of mature/ubiquitous interfaces to Apache hosted webpages and to C++, it might slower and have a larger flash & RAM footprint than necessary.
In an attempt to find a communications link that is smaller/faster than MySQL, I have an example that uses Javascript that does XML-RPC to a C++ app. But, this post way back in 02-24-2012, implies that xmlrpc is obsolete and could be replaced by something more modern (JSON, REST) but the posts lacks details about these methodologies.
Another option considered is something like Wt or other embedded libraries, but it will have a learning curve and web developers aren't likely to be familiar with it.
My question is: what would be a good architecture to implement a web interface for a custom C++ app on a resource-constrained device like a Raspberry Pi or other embedded Linux device?
Assumptions:
Apache is prefered because it fits in memory and web developers are familiar with it.
Interface should be 'modern'
pages are simple text-only, about 10 pages, 90% of the data fields
are read-only and the other 10% are editable fields.
The webserver is on a private network with no more than 3 users. The qty of users is
enforced using security/login.
Embedded ARM platform that boots from SD
CGI (launching a process for each transaction) is assumed to be slower
than necessary. FastCGI might be OK.
Similar questions found that didn't answer my question:
- Language Choice for Web interface on embedded device
- Designing Web Interface for Embedded System
Oh god. Apache? Why would you want such an overkill monster on an embedded device? I would suggest using a smaller server and instead of using cgi use a rest api handler. A very lightweight setup is to use uhttpd with ubus plugin and then to write your system code in C and just expose it's functionality through json api on ubus. You can then completely separate your web interface from your system code and you can minimize strain on the embedded server by only serving static html which you turn into a dynamic application with javascript and ajax.
No interpreter, no cgi, just ajax and ubus backend.
I do that and more on my rPI using Nodejs with the express, Socket.io, Mongojs modules
Related
I am totally new to tag reader hardware and Impinj. I have to collect rfid tag data from impinj R420 onto a computer which is connected by ethernet. How should I proceed to get the data with C++.
Impinj Speedway R420 offers different ways to develop off-reader host-based applications.
Impinj Octane SDK provides JAVA and .NET libraries, it hides all the complexity of LLRP protocol, helping to develop applications to control and collect data from the reader easily.
Impinj Octane LTK (LLRP Toolkit) provides JAVA, .NET, C++, and C libraries to develop applications, it gives you more control over the reader, using Low Level Reader Protocol (LLRP), using this library is much more complex, and it will take more time to finish your application.
My recommendation to your development is if you can use JAVA or .NET, use the Impinj Octane SDK libraries, if C++ is a must, the only choice you have is the Impinj Octane LTK. Both libraries are free of charge.
A third option is to get a license of the speedway connect software from Impinj, it runs inside the reader and provides different ways to send data out of the reader; to a socket, to a REST API through a POST HTTP message and serial USB. You can get a trial version of the Speedway Connect Software, it only has one limitation, it only reads up to 500 reads, then you will need to restart the software, it works for development purposes.
I want to make a smart little project where I receive data from an embedded linux (petalinux) into a phonegap app (Android).
The question is, what type of protocols are prefered?
I recently read about socket io and it looks great.
But how can I get the app to communicate from for example c or c++ to javascript and html?
The data will probably be stored into a sqlite database inside the embedded linux, or will someone prefer a better real time database system (RTDBS)?
Any ideas? Thanks.
What C++ software stack do developers use to create custom fast, responsive and not very resource hungry web services?
I'd recommend you to take a look on CppCMS:
http://cppcms.com
It exactly fits the situation you had described:
performance-oriented (preferably web service) software stack
for C++ web development.
It should have a low memory footprint
work on UNIX (FreeBSD) and Linux systems
perform well under high server load and be able to handle many requests with great efficiency
[as I plan to use it in a virtual environment] where resources will be to some extent limited.
So far I have only come across Staff WSF, Boost, Poco libraries. The latter two could be used to implement a custom web server...
The problem that web server is about 2% of web development there are so much stuff to handle:
web templates
sessions
cache
forms
security-security-security - which is far from being trivial
And much more, that is why you need web frameworks.
You could write an apache module, and put all your processing code in there.
Or there's CppCMS, or Treefrog or for writing web services (not web sites) use gSOAP or Apache Axis
But ultimately, there's no "easy to use framework" because C++ developers like to build apps from smaller components. There's no Ruby-style framework, but there is all manner of libraries for handling xml or whatever, and Apache offers the http protocol bits in the module spec so you can build up your app quite happily using whatever pieces make sense to you. Now whether there's a market for bundling this up to make something easier to use is another matter.
Personally, the best web app system I wrote (for a company) used a very think web layer in the web server (IIS and ASP, but this applies to any webserver, use php for example) that did nothing except act as a gateway to pass the data from the requests through to a C++ service. The C++ service could then be written completely as a normal C++ command line server with well-defined entry points, using as thin an RPC system as possible (shared memory, but you may want to check out ZeroMQ), which not only increased security but allowed us to easily scale by shifting the services to app servers and running the web servers on different hardware. It was also really easy to test.
i am writing an program in c++ and i need an web interface to control the program and which will be efficient and best programming language ...
Your application will just have to listen to messages from the network that your web application would send to it.
Any web application (whatever the language) implementation could use sockets so don't worry about the details, just make sure your application manage messages that you made a protocol for.
Now, if you want to keep it all C++, you could use CPPCMS for your web application.
If it were Windows, I could advice you to register some COM component for your program. At least from ASP.NET it is easily accessible.
You could try some in-memory exchange techniques like reading/writing over a localhost socket connection. It however requires you to design some exchange protocol first.
Or data exchange via a database. You program writes/reads data from the database, the web front-end reads/writes data to the database.
You could use a framework like Thrift to communicate between a PHP/Python/Ruby/whatever webapp and a C++ daemon, or you could even go the extra mile (probably harder than just using something like Thrift) and write language bindings for the scripting language of your choice.
Either of the two options gives you the ability to write web-facing code in a language more suitable for the task while keeping the "heavy lifting" in C++.
Did you take a look at Wt? It's a widget-centric C++ framework for web applications, has a solid MVC system, an ORM, ...
The Win32 API method.
MSDN - Getting Started with Winsock:
http://msdn.microsoft.com/en-us/library/ms738545%28v=VS.85%29.aspx
(Since you didn't specify an OS, we're assuming Windows)
This is not as simple as it seems!
There is a mis-match between your C++ program (which presumibly is long running otherwise why would it need controlling) and a typical web program which starts up when it receives the http request and dies once the reply is sent.
You could possibly use one of the Java based web servers where it is possible to have a long running task.
Alternatively you could use a database or other storage as the communication medium:-
You program periodically writes it current status to a well know table, when a user invokes the control application it reads the current status and gives an appropriate set of options to the user which can then be stored in the DB, and actioned by your program the next time it polls for a request.
This works better if you have a queuing mechanism avaiable, as it can then be event driven rather than polled.
Go PHP :) Look at this Program execution Functions
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.