I think, I got lost.
The problem is that I want to use event-loop based approach to implement simple HTTPS server (TLS 1.x). From what I've read so far, the best candidate to build an event loop is libev and the best candidate nowadays to work with TLS is libtls from the LibreSSL Project.
I do know that libev doesn't contain DNS and HTTP server (as opposed to libevent) so I have to either find another library that will add this capability or use implement it by myself. I found http-parser library that can help me with that.
Regarding the TLS thing, I believe the LibreSSL's libtls can be fit in without any problem, because it actually doesn't matter what kind of byte string you are processing.
So the main question is: am I right thinking that way? Is it really possible to use libev + http-parser + libtls in order to build event-loop based HTTPS server? Is is feasible to implement it at all? Am I missing smth important? Could you recommend other libraries which can help me implement HTTP server?
Big thanks in advance.
Related
I am implementing a messaging system using C++ and Qt. After much thought, I have determined that multicasting or a multicast-style technique will work best to solve my problem. However, I have learned about UDP's unreliability and believe it to be unacceptable.
My requirements are as follows:
Messages are to be sent in a binary serialized form.
From any given node on the network, I must be able to send messages to the other nodes.
Message delivery must be insured.
I have heard of OpenPGM and NORM as alternatives for UDP. If anyone has experience with either of these, could you please share?
I am also open to the possibility of implementing "reliable" multicast by myself, in the application layer, but I would prefer not to if there is a library that already implements this.
I am using C++ and Qt, therefore .NET or Java-based solutions are not acceptable unless they are open-source and I may port them to C++.
Thank you very much.
EDIT 20120816T1853 MDT: An additional question: would either PGM or NORM have to be implemented at the hardware/IP level? Or can they be overlayed on top of existing protocols?
We have implemented our own reliable multicast protocol over UDP called RSP, since we needed something cross-platform and at the time couldn't find a good solution between Linux and Windows. The Windows PGM implementation disconnects slow clients which leave the send window, whereas our implementation throttles the sender similar to TCP. Afaik OpenPGM can be configured to do the same.
The open source NORM at http://cs.itd.nrl.navy.mil/work/norm can be built as a library and has C++ API with Python and Java language bindings. If you ping the developer (me) via the mailing list, I can help get you started.
There is a large RFC division of reliable multicast protocols, and many implementations out there. It's a long time since I looked at this but there are TRAM, LRMP, ...
i want to make basic chat server using one of the event driven libarary .
but what to chose ? libevent or libev what is better ? which has better c++ support ?
which runes better in windows ?
what is faster ? faster to develop and understand
I prefer libev. It's very minimalistic and some of the benchmarks (probably old) I've seen indicate it performs better. The documentation is also quite good.
I prefer libevent because
1) it has an http server (both native one and as an external project),
2) http client (really useful if you need your event-driven server to use external services); libev has one, but it won't compile for me with recent libev
3) dns server (I use it to automatically redirect traffic for high availability)
4) IMO, better docummentation
5) is better maintained (see 2)
The choice isn't just between libevent and libev. Boost.asio is excellent. The programming model works well, and it is integrated into Boost which you should be using anyway.
If you're just learning, you are unlikely to notice any speed differences caused by the library.
I'm looking for a library to deal with multiple simultaneous HTTP connections (pref. on a single thread) to use in C++ in Windows so it can be Win32 API based. This is for a client application that must process a list of requests but keep 4 running at all times until the list is complete.
So far, I have tried cURL (multi interface) which seems to be the most appropriate that I have found but my problem is that I may have a queue of 200 requests but I need to only run 4 of them at a time. This becomes problematic when one request may take 2 seconds and another may take 2 mins as you have to wait on all handles and receive the result of all requests in one block. If anyone knows a way round this it would be very useful.
I have also tried rolling my own using WinHTTP but I need to throttle the requests so they would ideally need to be on a single thread and use callbacks for data which WinHTTP does not do.
The best thing I've found which would solve all my problems is ASIHTTPRequest but unfortunately it's Mac OSX only.
Thanks,
J
Have you looked at boost.asio? http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio.html
Its meant to scale well and has http server examples:
http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/examples.html
Did you tried Boost Asio ?
Is multiplataform and stellar performance, and with nice examples of HTTP.
http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio.html
Asio is a great library but it's generic, the HTTP examples are just that: examples, there's no support for redirection, authentication and so on.
I know of two libraries built on top of Boost & Asio that support the HTTP protocol: cpp-netlib and Pion Network Library but AFAIK neither directly supports what you want.
All that being said if you're comfortable with using libcurl it should be pretty easy to use the "easy" interface with callbacks and implement the requests queue yourself.
libcurl's multi interface supports exactly what you're asking for.
i would like to develop a c++ application that would list all url accessed with its response time within the pc. this probably would be transparent to the user, so it would be a dll.
can anyone gve me some sample codes or tutorials on th said matter.
or any tips and suggestion?!..
thanks alot:))
You should take a look at the fiddler plug-ins. This is not a trivial exercise. You need to do dependency injection to capture the wininet calls. Even so not all apps use the high level windows api to initiate connections. Applications that make TCP connections might last for a long time since not all TCP calls are simple web requests.
As Byron has said, this is a non-trivial exercise. You could do it using libpcap http://sourceforge.net/projects/libpcap/ having installed http://www.winpcap.org/ on Windows. Tutorials for using libpcap are around and you'd need to learn to filter out everything but http/https traffic, although once you've got to that stage it shouldn't be too hard. Try http://yuba.stanford.edu/~casado/pcap/section1.html for starters or http://systhread.net/texts/200805lpcap1.php. Both tutorials look reasonable.
I also feel I should point out that "transparent to the user" and "dll" are not equivalent ideas. A DLL is a set of library functions separate from an application that can be used by many applications - see http://en.wikipedia.org/wiki/Dynamic-link_library. A "standard" executable file (i.e. file ending in .exe) can still be transparent to the user if run, for example, as a Windows Service, which might be more what you are looking for.
Here's my question.
Right now I have a Linux server application (written using C++ - gcc) that communicates with a Windows C++ client application (Visual Studio 9, Qt 4.5.)
What is the very easiest way to add SSL support to both sides in order to secure the communication, without completely gutting the existing protocol?
It's a VOIP application that uses a combination of UDP and TCP to initially set up the connection and do port tunneling stuff, and then uses UDP for the streaming data.
I've had lots of problems in the past with creating the security certificates from scratch that were necessary to get this stuff working.
Existing working example code would be ideal.
Thank you!
SSL is very complex, so you're going to want to use a library.
There are several options, such as Keyczar, Botan, cryptlib, etc. Each and every one of those libraries (or the libraries suggested by others, such as Boost.Asio or OpenSSL) will have sample code for this.
Answering your second question (how to integrate a library into existing code without causing too much pain): it's going to depend on your current code. If you already have simple functions that call the Winsock or socket methods to send/receive ints, strings, etc. then you just need to rewrite the guts of those functions. And, of course, change the code that sets up the socket to begin with.
On the other hand, if you're calling the Winsock/socket functions directly then you'll probably want to write functions that have similar semantics but send the data encrypted, and replace your Winsock calls with those functions.
However, you may want to consider switching to something like Google Protocol Buffers or Apache Thrift (a.k.a. Facebook Thrift). Google's Protocol Buffers documentation says, "Prior to protocol buffers, there was a format for requests and responses that used hand marshalling/unmarshalling of requests and responses, and that supported a number of versions of the protocol. This resulted in some very ugly code. ..."
You're currently in the hand marshalling/unmarshalling phase. It can work, and in fact a project I work on does use this method. But it is a lot nicer to leave that to a library; especially a library that has already given some thought to updating the software in the future.
If you go this route you'll set up your network connections with an SSL library, and then you'll push your Thrift/Protocol Buffer data over those connections. That's it. It does involve extensive refactoring, but you'll end up with less code to maintain. When we introduced Protocol Buffers into the codebase of that project I mentioned, we were able to get rid of about 300 lines of marshalling/demarshalling code.
I recommend to use GnuTLS on both the client and the server side, only for the TCP connection. Forget about the UDP data for now. The GnuTLS documentation has example code for writing both clients and servers. Please understand that at least the server side (typically the TCP responder) needs to have a certificate; the client side can work with anonymous identification (although there is even an example without server certificate, using only DH key exchange - which would allow man-in-the-middle attacks).
In general, it is likely that you will have to understand the principles of SSL, no matter what library you use. Library alternatives are OpenSSL (both Unix and Windows), and SChannel (only Windows).
Have you tried the SSL support in Boost.Asio or ACE? Both use OpenSSL under-the-hood, and provide similar abstractions for TCP, UDP and SSL. Sample code is available in both the Boost.Asio and ACE distributions.
One thing you may need to keep in mind is that SSL is record-oriented instead of the stream-oriented (both TCP and UDP). This may affect how you multiplex events since you must, for example, read the full SSL record before you can call a read operation complete.
To help handle this with no changes to the application yo may want to look at the stunnel project (http://www.stunnel.org/). I don't think that it will handle the UDP for you though.
The yaSSL and CyaSSL embedded SSL/TLS libraries have worked well for me in the past. Being targeted at embedded systems, they are optimized for both speed and size. yaSSL is written in C++ and CyaSSL is written in C. In comparison, CyaSSL can be up to 20 times smaller than OpenSSL.
Both support the most current industry standards (up to TLS 1.2), offer some cool features such as stream ciphers, and are dual licensed under the GPLv2 and a commercial license (if you need commercial support).
They have an SSL tutorial which touches on adding CyaSSL into your pre-existing code as well: http://www.yassl.com/yaSSL/Docs-cyassl-manual-11-ssl-tutorial.html
Product Page: http://yassl.com/yaSSL/Products.html
Regards,
Chris