If a TLS error occurs, it could end up in a situation where the network handler code did not want to
read or write because it only had the error flag set. However, this was not handled, which left the
socket triggering in the event loop - but nothing was done to handle it.
This can easily cause a 100% cpu situation - the hub is still functioning though while this is
happening.
uhub has the ability to disconnect a 'ghost' user, e.g. if a user
reconnects then uhub will kick the existing user if it is still there.
However, this could also be triggered abusively by having two "tabs" or windows
connect at the same time from the same client. The process of connecting a new
client is rather expensive because it triggers a lot of updates on all connections.
With this change, uhub will only attempt to disconnect the existing client if
it is marked with the "flag_choke" flag, which indicates that messages must be
dropped simply because the client is not accepting data fast enough. This will
cause the new connection to fail because the user is already logged in.
This can be further improved by adding a timestamp for when the connection
previously was provable working. Which is possibly a better and more reliable
way of detecting ghost users.
another thread to the mainthread in a safe manner.
This is used for the DNS lookup code, and can also
be used by the signal handler to safely report actions back
to the application mainloop without using global variables.
This happened due to the network polling mechanism had nothing to poll
for, so it returned immediately only to be called again (during DNS lookup).
This fix introduces a control pipe that is polled for reading, althoug nothing
is ever sent to that pipe. But, it can be used instead of the signal
handler approach which is currently used for terminating the program.
the given amount of messages in the configured interval.
The previous behavior allowed n+2 messages in the interval, due to
two off by one comparison rules.
In addition, if flooding is detected then each new message after the flooding
is detected will reset the interval timer, which means the client
cannot send another message until the timeout interval expires.
This could essentially happen due to time drift,
high load, or the process being put in sleep for a while.
The reason is that recurring timers could be added to the same time slot
as the timeslot being handled.
This used to be a linear search O(n), but is now done
as a red-black tree O(log n) instead.
These operations can be further opimized with a hash-table
which would acheive near constant time lookups.
- Added a list_remove_first() which is generally better than list_remove()
provided you want to remove the first element.
- Added a list_append_list() to append and move all nodes from one list to
another.
Previously you would have to do something like this:
for (type foo = (type) list_get_first(list); foo; foo = (type) list_get_next(list)
{
/* code */
}
Now, you can instead write this as:
LIST_FOREACH(type, foo, list,
{
/* code */
})
Basically, boilerplate stuff including the casting is gone.
This API provides transparent asynchronous DNS lookups
with both IPv4 and IPv6 support, and in addition will try
to connect to all addresses until one of them work.
This implements the "happy eyeballs" algorithm provided that the client supports IPv6
and that the DNS records provides both IPv6 and IPv4 addresses.
This caused the backends to return an error code, which
in turn ended the mainloop. However, several other things
also might occur in the main loop, such as DNS lookups which
come prior to creating any connections that in turn would be monitored.
for certain lookups.
The rb_tree will act as a general purpose key/value storage, and
also give a performance boost in the cases where the other
simple alternative would be to use a linked_list.
On average this should give on average O(log n) lookups, while the linked_list
would be O(n) at worst.
Jan Vidar Krey