librelp 1.2.11
librelp 1.2.11 [download]
This new release of librelp is mostly a bugfixing release that fixes several issues, especially a potential segfault. The new version also has an API enhancement that adds a configurable connection timeout.
For more details, please take a look at the changelog below.
———————————————————————-
Version 1.2.11 – 2016-06-22
– bugfix: do not accept more than one “open” verb on a connection
closes https://github.com/rsyslog/librelp/issues/37
– bugfix: potential segfault when high-numbered fd is used in sender
When a fd (socket) with value >= 1024 was used by the client sender
process, the library could segfault in select(). This depended a bit
on the platform.
This patch solves the issue by replacing the select() call with
poll(). Note that we do not changed to epoll(), because
(a) we only wait on a single fd
(b) poll() is more portable
closes https://github.com/rsyslog/librelp/issues/38
– bugfix: make librelp not run in thight loop when out of sockets
If the process can no longer accept new connections (via accept)
because it has reached its file handle maximum, librelp runs in
a thight loop until either the client connection request is aborted
or a file handle becomes available.
This happens due to the fact that we get event notifications on
connection requests. As we can’t satisfy it, we librelp always
retries. Unfortunately, there is no socket call to cancel a
connection request, so we cannot push the client request out.
An alternative solution would be to close and re-open the
listening socket, but in that case it is uncertain if we ever can
re-aquire a socket (an easy DoS). So the best thing we can
probably do is delay retries a bit. We must be careful, however,
not to use a too long delay, as that would also affect other
connections. We could address that problem via a dedicated thread
for the listening process, but librelp is designed so that it can
be used by callers with any threading library and threading model,
and that would violate this design principle.
Judging the alternatives, a slight delay probably is the best
solution, especially as the situation is uncommon and will hopefully
not last too long. This patch implements that solution.
closes https://github.com/rsyslog/librelp/issues/34
– bugfix: flush the current recv frame if it exists if the client
session is restarting
Thanks to Nate Brown for the patch.
– API enhancement: add configurable connection timeout
Thanks to Nate Brown for the patch.
– bugfix: do not accept more than one “open” verb on a connection
closes https://github.com/rsyslog/librelp/issues/37
– bugfix: potential segfault when high-numbered fd is used in sender
When a fd (socket) with value >= 1024 was used by the client sender
process, the library could segfault in select(). This depended a bit
on the platform.
This patch solves the issue by replacing the select() call with
poll(). Note that we do not changed to epoll(), because
(a) we only wait on a single fd
(b) poll() is more portable
closes https://github.com/rsyslog/librelp/issues/38
– bugfix: make librelp not run in thight loop when out of sockets
If the process can no longer accept new connections (via accept)
because it has reached its file handle maximum, librelp runs in
a thight loop until either the client connection request is aborted
or a file handle becomes available.
This happens due to the fact that we get event notifications on
connection requests. As we can’t satisfy it, we librelp always
retries. Unfortunately, there is no socket call to cancel a
connection request, so we cannot push the client request out.
An alternative solution would be to close and re-open the
listening socket, but in that case it is uncertain if we ever can
re-aquire a socket (an easy DoS). So the best thing we can
probably do is delay retries a bit. We must be careful, however,
not to use a too long delay, as that would also affect other
connections. We could address that problem via a dedicated thread
for the listening process, but librelp is designed so that it can
be used by callers with any threading library and threading model,
and that would violate this design principle.
Judging the alternatives, a slight delay probably is the best
solution, especially as the situation is uncommon and will hopefully
not last too long. This patch implements that solution.
closes https://github.com/rsyslog/librelp/issues/34
– bugfix: flush the current recv frame if it exists if the client
session is restarting
Thanks to Nate Brown for the patch.
– API enhancement: add configurable connection timeout
Thanks to Nate Brown for the patch.
sha256sum: 84de48f46caba0106d8853af572aa7b625c82dfbcf5f7cd13d2e57cce786e929