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).
Related
I think it is better if I explain the situation so this doesn't seem too arcane a question. I want to release some starter code for a project I want some of my students to work on. The project involves scraping through some internet webpages and as such, I want to provide them with a URLStream class that will download the html of an input url and return it as a string to them.
The issue is that I can't seem to find a particularly nice way to deal with networking in a way that will be cross platform (the students have mac/windows/linux machines). I know of libraries like Boost asio and libCurl, but the issue with using these is that I can't enforce all my students download them. So my question is twofold:
Is there any nice way to provide them this cross platform networking code?
If a library is the only way to do this, is there any way to attach the library to the starter project so that students don't have to download it? I know this might be a stupid question but I can't seem to find out if this is possible.
Boost.Asio is really not suitable for your needs as it involves huge Boost and building at least some of its non-header-only libs. You can still consider Asio lib that can be used w/o Boost and is header-only lib, so much less hassle for you and your students. As it's probably the most popular and modern networking C++ lib this exercise can provide some useful experience to the students. Asio examples also have a simple HTTP client.
As a side note, are you bound to C++ for this assignment? It would be much simpler in Python or similar languages that provide networking out of the box.
The Berkeley sockets API is the most common low-level socket API. It is supported on all POSIX platforms which means both Linux and macOS will have it.
Even Windows have it, but with a slight twist since sockets aren't descriptors like they are on POSIX systems.
Using sockets directly will lead to more boiler-plate code, but it is definitely possible to use it to make a simple HTTP client that supports only simple GET requests.
There are many tutorials and references on using sockets. Beej's Guide to Network Programming seems to be a popular tutorial, which should have notes about the tweaks needed for Windows.
cross-platform C++ library for network programming
asio is a cross-platform C++ library for network programming that provides
developers with a consistent asynchronous I/O model using a modern C++
approach. It has recently been accepted into Boost.
I copied that from the info window in Synaptic. If you're using Linux, install the library (and its documentation) thus:
sudo apt-get install libasio-dev libasio-doc
I have to develop a simple XMPP server that will be included in a commercial project. I guess there is no server available that can be purchased with a royalty-free-license and that enables me to do the configuration and user management and the authentication from my own code.
The languages I can use are Delphi and C++.
I've already looked at the libraries listed at xmpp.org, but most of them seem to be client-only libraries or (as e.g. QXmpp) require QT which I have no experience of and consideres it to be a pure GUI framework.
Can anybody suggest a library I should take a closer look at? Does it make sense to familiarize myself with QT for this purpose (writing xmpp server;no GUI)?
Or is it better to just catch a stream parser (suggestions?) and code it myself?
Thanks!
Edit: The only library I could find for Delphi, IP*Works is a pure client library. I'm evaluation QXmpp now.
For the Delphi part of my question: I didn't find a library I think that is suitable for building a server.
For the C++ part, I think this post Non GPL C/C++ XMPP client library for embedded Linux (though it is for embedded and client) is answering my questions:
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.
and
Advice: when it comes to C++, there aren't many good xmpp libraries available.
So I think, QXmpp seems to be a good solution.
For other people searchig for this topic:
IMHO the documentation (especially for the server part) is a bit poor. The server example distributed with the qxmpp library is (of course) very basic: It is transporting chat messages. Distributing presence information, roster, subscription handling has to be implemented by you via extensions (inheriting QXmppServerExtension overwriting at least virtual function handleStanza). Don't parse the presence or iq stanzas in your own code. For the more common stanzas the libarary has classes implemented QXmppPresence, QXmppRosterIq etc.) that also can be used in your extension.
I'm starting development on a new Application, and although my background is mainly Mac/iOS based, I need to work on a Windows application for participation in their Imagine cup.
This project includes communication between clients through a socket connection (to a server, not ad-hoc), and I need for both Mac and Windows clients to be able to communicate with each other. I'd also like to not have to write this networking code twice, and simply write different native-UI code on both platforms. This makes the networking easier (I'm confident that two different platforms are not going to be interacting with the server in different ways) and allows for a native UI on both platforms.
Is C++ the best language for this task? Is the standard library the same on both platforms? I understand that I'll have to use Microsoft's Visual C++ library, as it seems as though it is hard to utilize C++ code from C#; is this true?
I've never really written a cross-platform application before, especially one that deals with networking between platforms.
If you're going to use C++, I second "the_mandrill" above by strongly recommending you look at ASIO in Boost - that is a great way to write the code once and support both platforms.
As to whether or not C++ is the right language is rather more subjective. My personal feelings are that if you need to ask, odds on, it's not the best approach.
Reasons for selecting C++ to implement networking code are:
Possible to achieve very low latencies and high throughput with very carefully designed and implemented code.
Possible to take explicit control of memory management - avoiding variations in performance associated with garbage collection.
Potential for tight integration of networking code in-process with other native libraries.
Potential to build small components suitable for deployment in resource constrained environments.
Low level access to C socket API exposes features such as socket options to use protocols beyond vanilla TCP/IP and UDP.
Reasons for avoiding C++ are:
Lower productivity in developing code compared with higher-level languages (e.g. Java/C#/Python etc. etc.)
Greater potential for significant implementation errors (pointer-abuse etc.)
Additional effort required to verify code compiles on each platform.
Alternatives you might consider include:
Python... directly using low level socket support or high-level Twisted library. Rapid development using convenient high-level idioms and minimal porting effort. Biggest disadvantage - poor support to exploit multiple processor cores for high-throughput systems.
Ruby(socket)/Perl(IO::Socket)... High level languages which might be particularly suited if the communicated information is represented as text strings.
Java... garbage collection simplifies memory management; wide range of existing libraries.
CLR languages (C# etc.) also garbage collected - like Java... WCF is an effective framework within which bespoke protocols can be developed... which may prove useful.
You also asked: "I understand that I'll have to use Microsoft's Visual C++ library, as it seems as though it is hard to utilize C++ code from C#; is this true?"
You can avoid Visual C++ libraries entirely - either by developing using a language other than C++, or using an alternate C++ compiler - for example Cygwin or MinGW offer G++... though I'd recommend using Visual C++ to build C and C++ code for Windows.
It's not hard to use C++ code from C# - though I don't recommend it as an approach.. it's likely overly complicated. Visual C++ can (optionally) compile "Managed Code" from C++ source (there are a few syntax extensions to grasp and there's a slightly different syntax for interoperation using Mono rather than Visual C++, but these are not major issues IMHO.) These CLR objects interact directly with C# objects and can be linked together into a single assembly without issue. It's also easy to access native DLLs (potentially written using C++ for the native architecture) using Pinvoke. All this is somewhat irrelevant, however, as the .Net framework has good support for low level networking (similar to that provided by Winsock[2]) in system.net - this provides a convenient C#-oriented interface to similar facilities, and will likely provide a more convenient API to develop against if using C# (or VB.Net or any of the other CLR languages.)
I would suggest that you take a look at Qt. IMO Qt is one of the best C++ libraries for doing cross-platform application. The benefits of Qt when comparing with Boost is that Qt have even GUI classes.
Best language is very subjective, but if you want portable fast code with useful abstractions and C style syntax the C++ is a good choice. Note if you do not know any C++ already there is a steep learning curve.
The library as defined by the ISO standard is by definition the same on each platform, however the implementation of it my be less or more compliant. That said, both gcc, clang and MSVC(post .net) all implement C++98 very well. So long as you don't use compiler specific extensions.
I strong recommend looking at boost asio (and the boost library in general) for your networking, it uses the proactor design pattern which is very efficient. However it does take some time getting your head around it.
http://www.boost.org/doc/libs/1_48_0/doc/html/boost_asio.html
Stick with the Standard library and boost and for the most part cross platform problems are not a major concern.
Lastly, I would avoid using the C++11 features for writing cross platform code, because MSVC, GCC and Clang have all implemented different parts of the standard.
If you want to spend a year and put in a 1000 hrs sure use boost::asio. Or you can use a library that's built around boost::asio that invokes C++ network templates. This is crossplatform network and you can find it here:
https://bitbucket.org/ptroen/crossplatformnetwork/src/master/
It compiles on Windows,Android, Macos and Linux.
That is not to say if your absolutely expert level in boost::asio you can do a tiny bit better in performance but if you want to get like 98% of the performance gains you may find it useful. It also supports HTTP,HTTPS,NACK,RTP,TCP ,UDP,MulticastServer and Multicast Client.
Examples:
TCPServer: https://bitbucket.org/ptroen/crossplatformnetwork/src/master/OSI/Application/Stub/TCPServer/main.cc
HTTPServer: https://bitbucket.org/ptroen/crossplatformnetwork/src/master/OSI/Application/Stub/HTTPServer/httpserver.cc
OSI::Transport::TCP::TCP_ClientTransport<SampleProtocol::IncomingPayload<OSI::Transport::Interface::IClientTransportInitializationParameters>, SampleProtocol::OutgoingPayload<OSI::Transport::Interface::IClientTransportInitializationParameters>,
SampleProtocol::SampleProtocolClientSession<OSI::Transport::Interface::IClientTransportInitializationParameters>, OSI::Transport::Interface::IClientTransportInitializationParameters> tcpTransport(init_parameters);;
SampleProtocol::IncomingPayload< OSI::Transport::Interface::IClientTransportInitializationParameters> request(init_parameters);
request.msg = init_parameters.initialPayload;
std::string ipMsg=init_parameters.ipAddress;
LOGIT1(ipMsg)
tcpTransport.RunClient(init_parameters.ipAddress, request);
I'm biased because I wrote the library.
You can also check for this communication library:
finalmq
This library has the following properties:
C++, cross-platform, async/non-blocking, multiple protocols (TCP, HTTP, mqtt5), multiple encoding formats (json, protobuf). Check the examples.
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.
(mingw32, windows xp)
Hello, I am attempting to migrate from Java to c++. I am confused and frustrated about finding, installing, and compiling non-standard c++ libraries. in Java it's so convenient they stuffed every functionality and documentation ever needed in java's standard api. Is there a list of essential c++ library such as Threading, gui, networking, image\ audio processing, xml, etc.etc. in one place? or possibly, offered as a single package?
I tried installing QT library for weeks and it wont even compile. in Java i used to learn by trial-and-error to learn new aspect of functionality, but that would be impossible if i can't fetch and run new api in the first place.
please, i need your suggestion, originally i wanted to break free of Java's abstraction, but now i just want to be able to use c++ before I decided shooting myself in the head.
The C++ standard library is extremely light. It contains nowhere near the functionality offered by the Java runtimes or by the .NET CLR.
The Boost libraries add a whole bunch of functionality to C++, but not much (if any) in the area of user interface.
For UI, there's the question of which platform you're targetting. If it's Win32, then you can use the straight Win32 API (mostly designed for C, but there are some C++ wrappers for parts of it). If you want cross-platform, then you're looking at QT or GTK (although there are others).
But, as Andrew already said: "why do you want to learn C++ anyway?". Don't get me wrong: I program in C++ for a living, and actually enjoy it (although I'm beginning to suspect a case of Stockholm Syndrome). If I had to start again, I'd go with a more modern language and environment (Java or C#; or Ruby or Python).
My advice would be: take it one step at a time.
First, figure out how to include a pre-built library in your code. I'd recommend starting with ZLib (it's got a very easy design to work with and it's also a useful tool to have available). Once you've got the pre-built library working, remove it and try compiling ZLib from the source code. Ask on Stack Overflow if you need help at any point, we'll get you through it.
By the time you get that working, you should have all the knowledge you need to get Qt compiled and installed too.
Threading, XML, Networking, some image generation, encoding and processing - boost provides those. As for XML, there's for example Arabica - it abstracts away platform-specific libraries by wrapping them with a nice standard C++ scent.
The GUI part is a different problem.
There's Qt, wxWidgets, gtk with c++ bindings (gtkmm), native libraries for each platform and their C++ wrappers (WTL is an excellent library for Win32), but as the C++ standard evolved and boost is becoming part of the standard (C++0x coming soon), there are no GUI frameworks that leverage those standard facilities and introduce their own instead. They do their job very well though.