| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Reduces the number of left-over timers to handle after many s2s
connections were started, leaving only the ones related to incomplete
connections.
|
| |
| |
| |
| |
| |
| | |
Skips a roundtrip through the main loop in case client-first data is
available already, if not then :onreadable() will set the appropriate
timeout.
|
| | |
|
| |
| |
| |
| |
| | |
There's the theory that the socket isn't the same before/after wrap(),
but since epoll operates on FD numbers this shouldn't matter.
|
| |
| |
| |
| | |
The :init() method sets a different timeout than the TLS related methods.
|
| |
| |
| |
| |
| |
| | |
Since TLS is a client-first protocol there is a chance that the
ClientHello message is available already. TLS Fast Open and/or the
TCP_DEFER_ACCEPT socket option would increase that chance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
So there's :startls(), :inittls() and :tlshandshake()
:starttls() prepares for plain -> TLS upgrade and ensures that the
(unencrypted) write buffer is drained before proceeding.
:inittls() wraps the connection and does things like SNI, DANE etc.
:tlshandshake() steps the TLS negotiation forward until it completes
|
| | |
|
| |
| |
| |
| |
| |
| | |
This should probably never happen, but probably does anyways.
A debug message would show the truth of the matter.
|
| |
| |
| |
| |
| | |
Nicer to get rid of a conditional that covers such a large portion of a
pretty big function.
|
| |
| |
| |
| |
| | |
These direct accesses are probably more optimized, but weird when the
module API has methods for these things.
|
| |
| |
| |
| |
| |
| |
| | |
Allows testing e.g. opportunistic writes or other settings easily in CI
or otherwise without editing the config file.
make integration-test PROSODY_NETWORK_SETTINGS='{"opportunistic_writes":true}'
|
| |
| |
| |
| |
| |
| |
| | |
To make it easier to test select and event without having to edit the
config file, e.g. in CI.
make integration-test PROSODY_NETWORK_BACKEND=event
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
net.http.files serving a big enough file on a fast enough connection
with opportunistic_writes enabled could trigger a stack overflow through
repeatedly serving more data that immediately gets sent, draining the
buffer and triggering more data to be sent. This also blocked the server
on a single task until completion or an error.
This change prevents nested opportunistic writes, which should prevent
the stack overflow, at the cost of reduced download speed, but this is
unlikely to be noticeable outside of Gbit networks. Speed at the cost of
blocking other processing is not worth it, especially with the risk of
stack overflow.
|
| |
| |
| |
| | |
It isn't quite an error.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When opportunistic writes are enabled this reduces the number of
syscalls and TCP packets sent on the wire.
Experiments with TCP Fast Open made this even more obvious.
That table trick probably wasn't as efficient. Lua generates bytecode
for a table with zero array slots and space for two entries in the hash
part, plus code to set [2] and [4]. I didn't verify but I suspect it
would have had to resize the table when setting [1] and [3], although
probably only once. Concatenating the strings directly in Lua is easier
to read and involves no extra table or function call.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may speed up client-first protocols (e.g. XMPP, HTTP and TLS) when
the first client data already arrived by the time we accept() it.
If LuaSocket supported TCP_DEFER_ACCEPT we could use that to further
increase the chance that there's already data to handle.
In case no data has arrived, no harm should be done, :onreadable would
simply set the read timeout and we'll get back to it once there is
something to handle.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The :init method is more suited for new outgoing connections, which is
why it uses the connect_timeout setting.
Depending on whether a newly accepted connection is to a Direct TLS port
or not, it should be handled differently, and was already. The :starttls
method sets up timeouts on its own, so the one set in :init was not needed.
Newly accepted plain TCP connections don't need a write timeout set, a
read timeout is enough.
|
| |
| |
| |
| |
| |
| | |
This should make sure that if there's data left to be written when
closing a connection, there's also a timeout so that it doesn't wait
forever.
|
| |
| |
| |
| | |
Things can behave unexpectedly when fed ANSI escape codes.
|
| |
| |
| |
| |
| | |
Useful for disabling certain behavior, ANSI colors etc when not
connected to a terminal.
|
| | |
|
| |
| |
| |
| |
| |
| | |
In some cases you might end up with both 'xmpp.example.com' and
'xmpp.example.com.', which are the same thing so no point in doing the
same checks twice.
|
| |
| |
| |
| |
| |
| | |
Clients would try to connect and receive an error or timeout, increasing
the time it takes to establish a connection. Probably not what you want.
If you really want IPv6 or IPv4 disabled, best remove the A or AAAA record.
|
| |
| |
| |
| | |
Why would you do this?!
|
| |
| |
| |
| |
| | |
If you set 'use_ipv4 = false' then you probably don't care much for the
host not resolving to the IPv4 address, and same with 'use_ipv6'.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may have mistakenly caused link-local addresses to be considered
global. May have caused mod_s2s and prosodyctl check dns to behave
incorrectly on networks using link-local IPv4 addresses. By my
guesstimate, these are extremely rare. Probably minimal impact beyond
a bit longer to establish s2s and some possible confusion from
prosodyctl check dns results.
Ref RFC 3927
|
| | |
|
| |
| |
| |
| |
| | |
This should a) prevent injection of text that looks like legitimate log
lines and b) not mangle tracebacks.
|
| |
| |
| |
| |
| | |
Made the pattern match a longer range than intended, but with no effect
since those characters are not present in the 'control_symbols' table.
|
| |
| |
| |
| |
| |
| | |
If unbound was initialized prior to this then the config change here
wouldn't apply, and it will again think that 127.0.1.1 has been found
in DNS.
|
| | |
|
| |
| |
| |
| |
| | |
This replaces an earlier method in a private extension that logged
pretty-printed XML, which broke due to the escaping added in util.format
|
| | |
|
| |
| |
| |
| | |
This will be used by the console logger for pretty printing.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I've had this color theme in a local debug module for some time and I
quite like it. The colors are from the XMPP logo.
Removes extra XML serialization implementation in favor of the standard
one. Also removes recursive str=str..more string building.
The new two-level gsub has the accumulator in C space so shouldn't be
too bad. The inner gsub calls use no callback, so should be fast and
not create all that much garbage.
No serious benchmarking has been done, but who cares if it looks nice?
|
| |
| |
| |
| |
| |
| | |
Always enable pretty printing if util.termcolours is available
util.termcolours can be nooped out to disable pretty printing.
|
| |
| |
| |
| |
| |
| |
| | |
This should offer some protection against doing evil things to
terminals. Doesn't protect against pure broken UTF-8 garbage however.
See #734
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
thought)
Character sequences could be split across chunk boundaries. Would require a bunch
of code to make that work reliably.
Only apply front_consumed on first chunk, and adjust buffer_pos accordingly.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
Makes merges and diffs easier to read and deal with, especially when
using tools to gather options from the codebase.
|
| |
| |
| |
| | |
Goal is to have some accountability for these privileged actions.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This doesn't really make sense today. It doesn't even work with
mod_auth_internal_hashed, which should be the default. And even with a
supporting authentication module, why would we just hand out the
password? One use case may be to recover a forgotten password. While not
yet included with Prosody, there are better ways to handle forgotten
passwords, usually by resetting them to a new password.
|