Having looked at several available http server libraries I have not yet found what I am looking for and am sure I can't be the first to have this set of requirements.
I need a library which presents an API which is 'pipelined'. Pipelining is used to describe an HTTP feature where multiple HTTP requests can be sent across a TCP link at a time without waiting for a response. I want a similar feature on the library API where my application can receive all of those request without having to send a response (I will respond but want the ability to process multiple requests at a time to reduce the impact of internal latency).
So the web server library will need to support the following flow
1) HTTP Client transmits http request 1
2) HTTP Client transmits http request 2 ...
3) Web Server Library receives request 1 and passes it to My Web Server App
4) My Web Server App receives request 1 and dispatches it to My System
5) Web Server receives request 2 and passes it to My Web Server App
6) My Web Server App receives request 2 and dispatches it to My System
7) My Web Server App receives response to request 1 from My System and passes it to Web Server
8) Web Server transmits HTTP response 1 to HTTP Client
9) My Web Server App receives response to request 2 from My System and
passes it to Web Server
10) Web Server transmits HTTP response 2 to HTTP Client
Hopefully this illustrates my requirement. There are
two key points to recognise. Responses to the Web Server Library are
asynchronous and there may be several HTTP requests passed to My Web
Server App with responses outstanding.
Additional requirements are
Embeddable into an existing 'C' application
Small footprint; I don't need all the functionality available in Apache etc.
Efficient; will need to support thousands of requests a second
Allows asynchronous responses to requests; their is a small latency to responses and given the required request throughput a synchronous architecture is not going to work for me.
Support persistent TCP connections
Support use with Server-Push Comet connections
Open Source / GPL
support for HTTPS
Portable across linux, windows; preferably more.
I will be very grateful for any recommendation
Best Regards
You could try libmicrohttp.
Use the Onion, Luke. This is lightweight and easy to use HTTP server library in C.
For future reference, that meets your requirement, take a look at libasyncd
I'm one of contributors.
Embeddable into an existing 'C' application
It's written in C.
Small footprint; I don't need all the functionality available in Apache etc.
Very compact.
Efficient; will need to support thousands of requests a second
It's libevent based framework. Can handle more than that.
Allows asynchronous responses to requests;
It's asynchronous. Also support pipelining.
Support persistent TCP connections
Sure, keep-alive.
Support use with Server-Push Comet connections
It's up to how you code your logic.
Open Source / GPL
under BSD license
support for HTTPS
Yes. it supports https with openssl.
Portable across linux, windows; preferably more.
Portable but not windows at this moment but it's portable to windows.
What you want is something that supports HTTP pipelining. You should make yourself familiar with that page if you are not already.
Yes, go for libmicrohttp. It has support for SSL etc and work in both Unix and Windows.
However, Christopher is right on the spot in his comment. If you have a startup time for each response, you are not going to gain much by pipelining. However, if you only have a significant response time to the first request, you may win something.
On the other hand, if each response has a startup time, you may gain a lot by not using pipelining, but create a new request for each object. Then each request can have its own thread, sucking up the startup costs in parallel. All responses will then be sent "at once" in the optimum case. libmicrohttp supports this mode of operation in its MHD_USE_THREAD_PER_CONNECTION thread model.
Following up on previous comments and updates...
You don't say how many concurrent connections you'll have but just "a TCP link".
If it's a single connection, then you'll be using HTTP pipelining as previously mentioned; so you would only need a handful of threads — rather than thousands — to process the requests at the head of the pipeline.
So you wouldn't need to have a thread for every request; just a small pool of workers for each connection.
Have you done any testing or implementation so far to show whether you actually do have problems with response latency for pipelined connections?
If your embedded device is powerful enough to cope with thousands of requests per second, including doing TLS setup, encryption and decryption, I would worry about premature optimisation at this level.
Howard,
Have you taken a look at lighthttpd? It meets all of your requirements except it isn't explicitly an embedded webserver. But it is open source and compiling it in to your application shouldn't be too hard. You can then write a custom plugin to handle your requests.
Can't believe no one has mentioned nginx. I've read large portions of the source-code and it is extremely modular. You could probably get the parts you need working pretty quickly.
uIP or lwip could work for you. I personally use uIP. It's good for a small number of clients and concurrent connections (or as you call it, "pipelining"). However, it's not as scalable or as fast at serving up content as lwip from what I've read. I went with simplicity and small size of uIP instead of the power of lwip, as my app usually only has 1 user.
I've found uIP pretty limited as the concurrent connections increase. However, I'm sure that's a limitation of my MAC receive buffers available and not uIP itself. I think lwip uses significantly more memory in some way to get around this. I just don't have enough ethernet RAM to support a ton of request packets coming in. That said, I can do background ajax polling with about a 15ms latency on a 56mhz processor.
http://www.sics.se/~adam/software.html
I've actually modified uIP in several ways. Adding a DHCP server and supporting multipart POST for file uploads are the big things.) Let me know if you have any questions.
Related
I am querying using solr search engine in my webapp. But right now I am calling solr server from python using
"http://localhost:8983/solr/select?q="
But I heard using unix socket instead helps reduce tcp/ip overhead. How to go about it? Thanks in advance.
None of the popular application containers support connections over local unix sockets, and usually for a good reason; it's a very, very, very small part of the request/response cycle, so unless you're actually seeing issues from tcp/ip setup and teardown, there should be very little reason for this.
Client libraries does not support local unix sockets either, as they exclusively talk TCP/IP to the server (and assumes an URL as an endpoint).
You can use EmbeddedSolr to integrate Solr directly into a Java project and use it without any request overhead, but the overhead from a search application will be small compared with the time taken to perform the actual search and handling the application container.
I m working with libcurl. It's very good (as client) and I used to open a socket to a server and then send my http packets.
I'm wondering if it's possible to develop http server with the libcurl. the http server will listen on a given port then when it receive a http packet then the http server return a need to a digest authentication.
I made some research in stackoverflow and in the curl website but without result.
Is it possible to do that with libcurl ? and how to do it?
To repeat what others have said: no, libcurl is not for servers. It is even said in the curl FAQ:
5.17 Can I write a server with libcurl?
No. libcurl offers no functions or building blocks to build any kind
of internet protocol server. libcurl is only a client-side library.
For server libraries, you need to continue your search elsewhere but
there exist many good open source ones out there for most protocols
you could possibly want a server for. And there are really good
stand-alone ones that have been tested and proven for many years.
There's no need for you to reinvent them!
You need some HTTP server library (since libcurl is only an HTTP client librart) I would suggest to use libonion but there are several other HTTP server frameworks (libmicrohttpd, POCO & Wt in C++, ....).
HTTP is a complex protocol, even if coding a server for a tiny subset (like plain GET requests, without all the useful features like conditional requests, encoding & compression, etc...) of it is reasonably feasible. Hence I recommend using a full-fledged HTTP server library, and that cannot be a tiny library.
I'm seriously considering the switch from Apache to nginx, and I'd like to understand nginx better - I'm no Apache guru either, so I think I'll learn more about Apache in the answers to these questions. I think it will be apparent from my questions that I really have a lot to learn in this area and have probably misunderstood much. But that's why I'm asking:
So does nginx have no equivalent of Apache's prefork MPM? If so,
then how is nginx different from the worker MPM? And if it's like
the worker MPM, then why aren't there the same concerns about thread
safety which make people not use Apache's mod_php with a worker MPM?
If a process is an OS process, and a process can
have multiple threads (similar to Java where java executable is the
single process and it can start multiple threads), how do
'requests' fit into this model? I understand that a client
request doesn't result in a new OS process with nginx, but does it result in a
new thread or can a thread handle multiple simultaneous requests? Or if not, then multiple sequential connections where when a thread has finished with one request it can handle another?
What is the relationships between 'requests' and 'connections'? If a client makes 10 requests, are these 10 connections, or is it 1 connection? How long does a connection last? I realize that if a client makes 10 requests over a period of a month, those could be part of the same session (if the session cookie persists), but surely that wouldn't be the same connection. So where's the line drawn for what constitutes a connection?
What are the different ways of using PHP from nginx? Unless I'm
mistaken, Apache has 3 (mod_php, mod_fastcgi, and mod_fcgid). For
nginx I've heard of PHP-FPM and FastCGI. Are there other options or
are these the only 2 ways, and if so how do they differ from each
other? I keep reading the PHP-FPM is another way of doing FastCGI
so I'm not exactly sure what the difference is.
If there are 10 clients connected to the server accessing PHP pages,
how many processes will I see when running the 'top' command if using
nginx, and what will they be named? (I imagine the answer depends on the response to the question in the previous paragraph.) If this was with Apache prefork MPM and
mod_php, if I understand correctly then I think I'd see 10 httpd
processes when running 'top'.
How many ports on my server will now be occupied? Before it was just port 80 by Apache. Now I imagine there'll be port 80 by nginx, plus some other port for nginx to communicate with the thing that's actually processing the PHP. And what exactly is that thing that runs the PHP, is it the 'PHP' executable, or 'FastCGI', or something else?
So if nginx is configured to use multiple 'backend' PHP processors (is this possible?) how many APC instances will there be? And how would requests from nginx be handed to them (e.g. would it use the session cookie to send the same user back to the same PHP processor?)
So many questions, I know, but hopefully some out there who actually understand all this can help me understand as well. I really want to! Thanks.
This article should answer pretty much everything: http://arstechnica.com/business/news/2011/11/a-faster-web-server-ripping-out-apache-for-nginx.ars about Apache v.s. Nginx
As for the other questions:
3) A request is just that, a request for some resource on the server. GET /index.html is one request. POST /formhandler.php is another request. A connection is the literally TCP socket setup that links the client browser to the server. A connection is what the request will travel through. One connection can handle multiple requests, or it can handle only one request. It depends on if HTTP Keep-Alives are allowed/requested, and what mood the client and server are in that day. Best case, 1 connection handles 10 requests, requiring only one TCP handshake sequence. Worst case, each request goes over a separate connection, requiring 10 tcp handshakes.
6) There'll be one or two listening ports open on the server (port 80 for regular, 443 for ssl, maybe). Any number of requests can be multiplexed onto a single port. There'll never be LESS than one port held open by the webserver, but should never really be more than 1 or 2 either.
So, i am assuming that i will need to use sockets(i am a newbie to C).
The program will be for Windows(in pure C). And i shall be using these examples
http://cs.baylor.edu/~donahoo/practical/CSockets/winsock.html
My question is, instead of the client program connecting via TCP, i want the server to accept connections via a web browser i.e via HTTP.
So if the server program is running you type http://yourip:port/?gettemps and the server responds, but how do i do it?
As you might have guessed, this program will be for monitoring temps, remotely, via a web browser. But not for the CPU, for the GPU using AMD's ADL library(so yeah, only AMD cards).
The simplest option that is supported by most web servers is CGI - Common Gateway Interface.
Microsoft, of cource, has their own way of running web apps - ISAPI.
HTTP is quite a big standard, you might want to use some library such as libcurl to handle the details for you.
If you decide to code it yourself, HTTP is running over TCP so you first need to open a TCP socket at the standard HTTP port 80. Then simply listen on the socket and parse the incoming HTTP data - a great summary is given here: http://www.jmarshall.com/easy/http/.
Web browsers sends http get request to the server via tcp. If you are writing a web server from scratch than, you will need to parse data from web browser. http get request are string like for example GET /images/logo.png HTTP/1.1. So tokenize that string as it comes through tcp and get the command.
As you received your commands to the server call appropriate functions to handle your request.
Here is an great example of simple http server. You might want to make server multi-threaded as you may have multiple simultaneous users.
If you have already set up your web server to run the app on the appropriate port you can use getenv("QUERY_STRING") to access the web equivalent of command line parameters.
It would be better to call your program directly rather than just using the server to access a single default program as your example does, thus you could use http://yourip:port/yourprogram?cmd=gettemps. In this example getenv("QUERY_STRING") would return 'cmd=gettemps'.
I currently need to make the silverlight 4 in-browser app that can receive push messages from the server. I presume using sockets is the best way, and will also allow a connection between server and client to transfer data and update the page.
But I am worried about firewalls and/or proxy servers.
Is it possible to have push technology, or even sockets at all, whilst behind a proxy that may block everything that isnt on port 80?
Or is it possible to have socket connections on port 80 which would be perfect because it would bypass both proxy and firewall. I am aware that there is a set range of ports available for silverlight, so im meaning a work around.
While on the subject...Would sending a mass block of data from silverlight be faster through sockets, ASP.NET AJAX, or connection to an ASMX web service?
Thanks a ton!
Here's a great article on WCF Polling Duplex (HTTP Long polling or COMET Style) hopes this helps. It's a bit out dated by the content will get you started.
http://tomasz.janczuk.org/2009/08/performance-of-http-polling-duplex.html
You can't connect to TCP socket with port 80 in Silverlight. As you've state there is a limited range of ports (4502-4534) you can connect to and thats it.
Yes firewall will be a concern, just as with other applications such as RDP remote access the firewalls involved between the client and server need to allow connection through one of the allowed port numbers.
Speed of data transfer is largely a function of its encoding. (I don't think AJAX is in the picture here). Ultimately sockets with binary encoding tend to be a bit quicker especially for frequent small transmissions. Whereas HTTP suffers with a bit more overhead however you are much less likely to have a problem with a firewall.
Unless you have a really, really good reason to use sockets use a HTTP based protocol instead. If you abstract out this part of your app reasonably well you could always swap it later.
Have you considered using a WCF PollingDuplex Channel? This allows you to create the "push" from server mechanism whilst sticking with HTTP. In addition much of the plumbing is done for you.