Proxygen, Facebook's C++ HTTP Framework
code.facebook.com
code.facebook.com
In addition to HTTP/1.1, Proxygen (rhymes with "oxygen") supports SPDY/3 and SPDY/3.1. We are also iterating and developing support for HTTP/2.
We already use the Proxygen HTTP code for the webserver part of HHVM internally. We hope to release that webserver part too (in the HHVM project).
Our reverse proxy uses proxygen and does TLS termination too, yes.
It's early stages for the proxygen open source project. Maybe further down the road we'll provide off-the-shelf binaries, but we think the library is already interesting enough to warrant a release.
Also the previous load balancers had constraints we weren't willing to accept - they required special connectivity to our networks, we could not use particular combinations of options, and we had to rely on vendors to solve problems that most of their customers were not encountering and/or able to detect.
I'm surprised more systems don't take this approach of doing more work in L7 proxies.
Apache Traffic Server only got SPDY support in a release about 45 days ago according to their release notes.
There are many other relatively basic features besides those, and similar considerations exist for the other projects that existed back then (and even now).
I don't work at FB but near the bottom in the comments you can see that they build on existing C++ libraries that have been tried/tested. We do the [same thing][1] with smaller services simply because its easier in the SDLC process to move libraries that are already in-house.
[1]: https://github.com/bloomberg/bde/tree/master/groups/bsl
- the license is terminated when one files a claim against _any_ of Facebook's software or services (IIRC Apache License gets terminated only when filed against the software)
- the license also terminates when you claim that "any right in any patent claim of Facebook is invalid or unenforceable"
The second clause seems very agressive (or pro-patent) to me, which makes me feel sorry for the developers of Proxygen, since IMO such a clause would harm the acceptance of the software outside Facebook.
It would be great if you reconsider the patent license.
Disclaimer: I am developer of H2O, an open-source HTTP/1 and HTTP/2 library, so there is obviously a conflict of interest here. But I wanted to leave a comment anyways since, honestly, I feel sorry if my friends at Facebook needs to go with this kind of license.
Then everyone goes and complain about the GPL vs BSD.. but this is waaaaaaaaay worse.
Does somebody like me have a reason to check out Proxygen?
If you're interested in how HTTP frameworks are designed and implemented, I'd definitely suggest checking it out though. This project is initially going to be more interesting to people integrating with HTTP quite directly.
I've cruised through the Proxygen code base and there are definitely some head scratchers.
http://stackoverflow.com/questions/388242/the-definitive-c-b...
I'd recommend "C++ Primer" first, "Effective C++" second, and "The C++ Programming Language" as a reference. Other must haves are "Modern C++ Design", the other Scott Meyers books, and the Herb Sutter books.
C++14 is mostly fixing what was left out in C++11, so the book is already a good starting point.
C++14 is definitely cool, I use JVM/.NET nowadays at work, but am an old C++ dog (since 1993), so I always used the language on a few side projects.
C++14 kills quite a few complaints I had about the language. Now if we just could get proper modules.
It is show how to make proper use of C++11 without any bad C influences.
Docs: http://icu-project.org/apiref/icu4c/classicu_1_1UnicodeStrin...
I have a question -- in particular, the blog post mentions that the framework "includes both server and client code", any my question is about the second part :-)
I'm wondering, how does it compare to the other C++ HTTP client solutions: Is it closer to higher-level libraries like cpp-netlib, Casablanca, or POCO -- or more on a lower-level / comparable to Asio (or Boost.Asio)?
In your view, what are the main relative advantages/disadvantages (namely in the scenario mentioned in the blog post, i.e., integration into existing applications)?
I'm currently working on my own library using libuv, http-parser, nghttp2 and wslay, which is very similiar in it's use to node.js. As you might guess a echo server is therefore only about 15 lines of code, but about as performant as your framework. The downsite is that it's not as flexible due to the missing "4-part abtraction" (really… an excellent idea).
That's why your release somehow saddens me: When I'm going to release my framework to the public, it might be pretty good for cross platform apps etc. compared to others, but it will never ever be as popular as yours. Heck… I don't even have 10 twitter followers.
Also Facebook is a group of people so saying "your" doesn't really sound right.
In no way I intended to say that my framework is better overall, but I do think it's better suited for simple things, like apps.
In fact, I think I will integrate something like their "four-part abstraction", because I really think this is a great idea.
Building simple, standalone http services with good performances seems to me what those two projects (proxygen and golang) are really about.
Now the question is, how much faster using C++ is, and how much safer and faster writing golang is...
When most laypeople think about "Google", they probably mean the search engine. I cannot imagine the serving system of Google - the part that actually retrieves the results and ranks them - ever being written in anything but C++. The scale of data that it operates on is just too large, the complexity of the code too high, and the CPU budget per request too small.
Now, there are other binaries in the search serving stack that I think should ideally be written in Go. I said as much when I was at Google, though I doubt it'd ever happen simply because of inertia. But that's probably not what people are thinking of when they say "Google-scale".
Source: I worked in search for 5+ years.
I guess the "hotspot" would be the code that has to merge the top results from the different nodes and actually deliver top rated 10 items to the user?
Plus, there are still lots of scenarios where Go tooling still doesn't provide support for. They will eventually, but not if you are starting a project today.
'start_dir=`pwd`; trap "cd $start_dir" EXIT;'...
No need to say that the script can be dangerous, in case directory change fails for instance, there's no checks but sudo make uninstall is run anyway in another dir than the intended one.
1. You don't need bash, but rather use /bin/sh to be more compatible with other shells (I don't have bash, neither does a lot of other systems after latest Shellshock incident). There's really no need to limit it to bash (bash is one of many shells but very commonly mistaken for "shell script").
2. The script is executed in a subshell, so the directory your script is in when exiting is irrelevant, it doesn't affect the caller at all. Try by creating a new script that just does 'cd a_dir_that_exists' and run it from a terminal. :)
3. set -e makes the program stop in case of _unhandled_ errors yes, so you're right, the example I gave is indeed wrong and it would stop on the failed cd attempt.
Instead of using '|| true' (to deliberatly ignore errors), the std way to do it is '|| :' (which doesn't fork the true binary). However I would really recommend taking care and handling possible errors.
Do you think that C++ is a well suited language for this kind of processing? Is it possible to say, now this project is in a mature state, that other languages (e.g. Rust) could have helped make your implementation simpler?