This question already has answers here:
Biggest differences of Thrift vs Protocol Buffers? [closed]
(15 answers)
Closed 7 years ago.
I've been using PB for quite a while now, but, Thrift has constantly been at the back of my mind.
The primary advantages of thrift, as I see it are:
Native collections (i.e, vector, set etc) vs PBs repeated providing functionality similar to, but not quite like (no iterators unless you dig into RepeatedField which the documentation states "shouldn't be required in most cases").
A decent RPC implementation provided, instead of just hooks to plug your own in.
More officially supported languages (PB offers "official" support for Java, C++, Python)
The cons of Thrift:
The RPC implementation means I can't plug in my own (for example) encryption/authentication layer on top.
Windows support doesn't seem to be great.
PB definitely seems to have, if not better, more accessible documentation.
Neutral:
Unknown size of .lib/.dll on Windows (Thrift).
Large size of .lib on Windows (PB, but it does offer a -lite which is significantly smaller).
Speed wise, they both seem to be similar.
I'm not quite ready to take the plunge and switch to Thrift yet, can anyone offer me more pros/cons, or reasons to go one way or the other?
Thanks!
As I've said as "Biggest differences of Thrift vs Protocol Buffers?" topic :
Referring to Thrift vs Protobuf vs JSON comparison :
C++, Python, Java - in-box support in Protobuf and Thrift.
Protobuf support for other languages (including Lua, Matlab, Ruby, Perl, R, Php, OCaml, Mercury, Erlang, Go, D, Lisp) is available as Third Party Addons (btw. Here is SWI-Prolog support).
Protobuf has much better documentation and plenty of examples.
Protobuf objects are smaller
Protobuf is faster when unsing "optimize_for = SPEED"
Thrift has integrated RPC implementation, while for Protobuf RPC solutions are separated, but available (like Zeroc ICE ).
Protobuf is released under BSD-style license
Thrift is released under Apache license
Additionally, there are plenty of interesting additional tools available for those solutions, which might decide. Here are examples for Protobuf: Protobuf-wireshark , protobufeditor.
You might want to analyse your need first:
Do you need a protocol-agnostic format? For example, do you want to implement a custom protocol or need 100% portability? In such a case use PB.
If you are fine with the default protocol of Thrift, and you need a protocol to begin with, by all means, go with Thrift.
Hope this helps.
Our project's main reason to stick with Thrift over protocol buffers was that protocol buffers don't auto-generate a complete RPC server, and existing solutions for PB seemed to all be fairly unstable. Just my $0.02.
You need to specify your use case(s) in detail. Else this is a "Which is better, a car or a truck?" question.
Related
From here:
Storm was designed from the very beginning to be compatible with multiple languages. Nimbus is a Thrift service and topologies are defined as Thrift structures. The usage of Thrift allows Storm to be used from any language.
I see that a topology created in java get deployed by serializing the topology (spouts, bolts , ComponentCommon) as a Thrift datatypes and then gets deployed on Nimbus. In Java it is easy to serialize the object with its methods and data. So on the other side Nimbus just needs to create objects and invoke them. (i might be missing detail here but I hope I got the point correctly)
But I wonder how to write the topology in C++ and deploy it the same way. Does thrift help to serialize the c++ based topology and Nimbus deploys/executes the topology in the same way as for Java?
I have seen the links link1 link2 in this regard and the only solution seems to be using a Shelbolt. which invokes the process and communicates with it over standard i/o.
In order to use the Thrift way, do we need to rewrite the storm core also in C++? Also why use Thrift when it supports only JVM languages? Thrift doesn't seem to be used at all for languages like python/c++.
I'm not sure if I'm understand your question correctly -- in my understanding you're asking Is it possible [without the Shebolt hack] to use Storm [with Thrift as comm protocol] with C++-written bolts and with C++ as the language that creates the topology.
Because of the lack of other answers to this question and based on my own research I assume there is no finished, usable implementation for your problem.
Therefore if you really have to use Storm (its common usecase is the JVM, so even if it could theoretically work with any language, it doesn't mean there is an ecosystem for other languages) and C++, you have no option but to use the Shebolt hack or modify Thrift yourself.
As you know, thrift itself has also been ported to C++. Therefore it is possible to re-build the API calls in C++. Basically, you'd need to port the Java TopologyBuilder. On the C++ side, you could start with the Thrift C++ tutorial.
This is also some kind of a hack, as you basically just rebuild half of the stack (in this case ontop of Thrift), but in general you have very few other options with a system design like Storm.
For example, the MySQL binary protocol has been rebuilt from-scr
Unless anyone has done the work for you (which I would have completely missed in my research) I see no option than to do it yourself (maybe even storm is not the best tool for your usecase!?)
If another hack (which might be even more complex and maybe even slower) besides ShellBolt is good enough for you, you could try starting a JVM from inside C++, e.g. see this SO post. I would not recommend this.
If you need an alternative distributed task queue, I have had good experience with Celery in Python environments, however I have no experience in using it in C++ directly (I usually control Python with ZeroMQ, or write my own ZeroMQ-based queues where necessary, but this is no universal solution).
Does anyone know of a good non GPL C/C++ XMPP client library that works for embedded Linux in ARM machines?
I've checked out txmpp but the last update seems to be 2 years ago.
qxmpp seems to require Qt, which I'm not sure is supported in embedded Linux. Also, AFAIK Qt is for GUI, so I'm not sure why a library requires it.
I also checked out gloox, but it's GPL and seems to be over a year old too.
Non GPL C/C++ XMPP client library for embedded Linux
libstrophe - dual-licensed under Mit/GPLv3. However, I'm not sure if it will compile on ARM, although it should be fairly portable.
so I'm not sure why a library requires it.
Because Qt provides XML parser and signal/slot framework. XMPP requires XML parser, and signal/slot framework makes your life easier. If you try implementing entire XMPP with all extensions in OOP fashion, you'll need something similar to Qt. If you simply need to send a command or two, then bare bones solution will do.
libstrophe is bare bones. You won't get dozens of wrappers representing different xmpp concepts (and legion of extensions), but you'll be able to send commands you need/want. You'll have to read XMPP specifications, of course.
Advice: when it comes to C++, there aren't many good xmpp libraries available.
I think it happens for following reasons (personal opinion):
Too many protocol extensions
It is easy to get distracted while making xmpp libraries. Xmpp contains fairly large number of possible errors, and OOP-minded programmist will be extremely tempted to make a class for everything, which doesn't work well in this scenario and requires something like Qt 4 to make it work properly.
XMPP requires XML parser.
As a result, it might make sense to try python - IF your embedded platform can handle it. For python, there's xmpppy. Although I strongly dislike python, I think it'll be easier to work with XMPP in python using xmpppy than in C++ using libstrophe. This is because xmpp requires plenty of key-value pair lists, and python represents such constructs in more "natural" way, using dictionaries.
I had the same problem so i rolled my own. Released under BOOST license; http://deusexmachinae.se/dxmpp
It only supports core functionality + proper authentication (including TLS and SCRAM-SHA-1).
I am looking for a library for native C++ (library source code has to be gcc compatible and portable across Linux and Windows) that does what WCF does in its very basic form - i.e. OperationContracts and DataContracts in a client-server environment, with data exchanges in binary format (binary serialization).
Ideally I'd like to use a library to achieve this. So if there's a library already available that compiles OperationContracts and DataContracts into rich C++ classes with metadata for reflection which can be consumed in our code and with client-server TCP communications built-in (i.e. a rudimentary implementation of WCF's functionality without the need to be compatible with WCF at all), please point me to it.
If not, implementing them myself (unlikely due to time constraints), I could use boost::serialization for DataContracts but how would I implement OperationContracts?
It's not necessarily compatible with gcc--so it's somewhat tangential to the precise question asked here--but I'd like to include a reference to the Windows Web Services API, Microsoft's native-code counterpart to WCF (for Windows systems).
From this secondary article:
WWS is designed from the ground up to be a completely native-code implementation of SOAP, including support for many of the WS-* protocols. WWS is, strictly speaking, exposed through a C API, making interoperability with other languages and runtimes very straightforward, but it is the C++ developer who will likely benefit the most.
I have found one that fits the purpose called "RCF" (Remote Call Framework) by Delta V Software. It's open source (GPLv2 or US$195 closed source). So far in my testing, it's working very well. According to the site, companies like HP, Ericsson and Siemens are users of the library.
Apache Thrift is another option you might consider,
http://en.wikipedia.org/wiki/Apache_Thrift
I have a set of functions in C/C++ that I need to be available to accept calls and return values to C/C++ code in a remote location, similar to RMI on the java platform. With RMI the Java methods are set up through the rmiregistry and remain available in memory to accept requests. I'm looking for similar functionality in C/C++, but i'm a bit confused with all the options that are out there. Is this type of scenario that CORBA was intended for and if so, is this still the best technology to use or are there better options out there. I've read about XML-RPC, CORBA, and a few others but i'm not sure which of these is what i need.
Thanks for your help.
Mike
Is this type of scenario that CORBA was intended for and if so, is this still the best technology to use or are there better options out there.
Yes, this is what CORBA was intended to solve. Whether it's "best" is subjective and argumentative. :) I can say, from my personal experience, I don't miss my short experience with CORBA and would suggest you explore other options.
I've read about XML-RPC, CORBA, and a few others but i'm not sure which of these is what i need.
As you seem to be aware, you're looking for any technology that implements RMI (also frequently called RPC). It's not built-in to C/C++.
On Linux, there is SunRPC. I would also recommend looking at Google protocol buffers, which provide a mechanism for serializing data as well as an interface for defining RPC services. There are several service implementations available, but I don't have experience with the service implementations.
On Unix-like platforms, you're probably looking for Sun RPC (remote procedure calls).
CORBA is also relevant but has a more natural binding to languages with object oriented capability.
There's no built in method for accomplishing this in C or C++. That said there are several libraries that can accomplish this.
If you're on Windows, then the best answer is probably DCOM, which is part of the OS itself. I'm not sure about other platforms.
I shall suggest either CORBA or any webservice library available
CORBA is a reasonable choice for you (though it may be a little bit old technology for now). I have been using CORBA for several years in my previous job.
I should say, learning curve for CORBA is kind of steep, and you need to cater a lot of extra setup, but once it it done correct, it become smooth to use. (The problem is it takes really some time to use it correctly)
Webservice is an de facto industrial standard now, and I believe C++ will have some reasonable implementation and library for that. CORBA cover more features than WS but those feature are seldom used in simple systems.
I need to use XmlRpc in C++ on a Windows platform. Despite the fact that my friends assure me that XmlRpc is a "widely available standard technology", there are not many libraries available for it. In fact I only found one library to do this on Windows, (plus another one that claims "you'll have to do a lot of work to get this to compile on Windows). The library I found was Chris Morley's "XmlRpc++". However, it doesn't have support for SSL.
My question therefore is: what library should I be using?
I've written my own C++ library. It's available at sourceforge:
xmlrpcc4win
The reason I wrote it rather than using Chris Morley's was that:
The Windows "wininet.lib" library gives you all the functionality for handling Http requests, so I'd rather use that. As a result, I only needed 1700 LOC.
"wininet.lib", and therefore my implementation, supports HTTPS
Chris Morley's use of STL containers was quite inefficient (Chris, mail me if you read this).
Until I wrote my own library, (see above) here was my answer:
Currently, the XmlRpc++ library by Chris Morley is the only public domain/LPGL XmlRpc implementation for C++ on Windows.
There are a couple of C++ implementations for Linux, either of which could be presumably easily ported to Windows, but the fact seems to be that no-one has yet done so and made it publicly available. Also, as eczamy says, "The XML-RPC specification is somewhat simple and it would not be difficult to implement your own XML-RPC client."
I'm using Chris Morley's library successfully, despite having had to find and fix quite a number of bugs. The Help Forum for this project seems to be somewhat active, but no-one has fixed these bugs and done a new release. I have been in correspondence with Chris Morley and he has vague hopes to do a new release, and he has contributed to this stackOverflow question (see below/above) and he claims to have fixed most of the bugs, but so far he has not made a release that fixes the many bugs. The last release was in 2003.
It is disappointing to me that a supposed widely supported (and simple!) protocol has such poor support on Windows + C++. Please can someone reading this page pick up the baton and e.g. take over XmlRpc++ or properly port one of the Linux implementations.
There are dozens of implementations of the XML-RPC implementations, some in C++, but most in other languages. For example, besides XmlRpc++ there is also XML-RPC for C and C++. Here is a HOWTO on how the XML-RPC for C and C++ library can be used.
The XML-RPC specification is somewhat simple and it would not be difficult to implement your own XML-RPC client. Not to mention, it would also be possible to take an existing XML-RPC implementation in C and bring into your C++ project.
The XML-RPC home page also provides a lot of useful information.
Just wanted to note a couple of items:
The source in the cvs repository for XmlRpc++ has support for OpenSSL (although I have not tried it, it was contributed by another developer).
Most of the reported bugs are fixed in cvs; I don't have access to a linux machine at the moment, so I haven't made an official release.
XmlRpc++ is not public domain. It is copyrighted and licensed (LGPL).
Thanks,
Chris Morley
I was able to get Tim's version of xml rpc working with https and with basic username / password authentication.
For the authentication:
1) the username and password need to be passed to the InternetConnect(...) function
2) an http request header of "Authorization: Basic base64encoded(user:pass)" needs to be added prior to sending the HttpSendRequest(...) command.