Older Linuxes sometimes respond to some nmap probes by having accept()
return a success but with socklen 0. That can lead to confusing behavior
when you go to process the sockaddr.
You could previously do this with evbuffer_peek() and some memcpys,
but it was a bit more work than most folks wanted to get into.
Closes sourceforge ticket 3108072
Some people use event_base_once(EV_TIMEOUT) to make a callback get
called "immediately". But this is pretty roundabout: it uses the
timeout heap to immediately put the event onto the active queue, when
it could just use event_active. Additionally, it can lead to
surprising re-ordering behavior.
This patch changes event_base_once so it bypasses event_add() and
called event_active() directly on a pure-timeout event with an empty
timeout.
I thought we'd fixed the cases where this could come up, but
apparently having an event_base_break() happen while processing
signal events could get us in trouble.
Found by Remi Gacogne. Sourceforge issue 3451433 .
Previously, if some sender were generating data to read on an
OpenSSL connection as fast as we could process it, we could easily
wind up looping on an openssl do_read operation without ever
considering other sockets.
The difference between this and the original method in
consider_reading() is that it only loops for a single completed
*frame* instead of looping until fd is drained or an error condition
was triggered.
{Patch split out by nickm}
OpenSSL bufferevents with deferred callbacks enabled under high load will
spinlock in the function consider_reading(). This loop continues until all
data has been read.
Because of this condition; openssl bufferevents will never return back into
event_base_loop() until SSL_read has determined data is no longer ready.
As of yet I have not found a reason why this while loop exists, so this patch
just swaps out while for if.
If needed I can write same code which would trigger this effect; optionally
libevhtp has a test.c program which can be run with the following flags:
./test -s <keyfile.pem>
curl -vvvv -k -d@<HUGE_ASS_FILE> https://127.0.0.1:8081/
The return data will include the number of times the readcb got data and the
length of that read.
Without this patch, you are likely to see a small amount of "bytes read....",
otherwise the "bytes read..." return data should show much more reasonable
numbers.
