| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
Supported by the other net.server implementations already, but not used
anywhere in Prosody.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the underlying TCP connection times out before the write timeout
kicks in, end up here with err="timeout", which the following code
treats as a minor issue.
Then, due to epoll apparently returning the EPOLLOUT (writable) event
too, we go on and try to write to the socket (commonly stream headers).
This fails because the socket is closed, which becomes the error
returned up the stack to the rest of Prosody.
This also trips the 'onconnect' signal, which has effects on various
things, such as the net.connect state machine. Probably undesirable
effects.
With this, we instead return "connection timeout", like server_event,
and destroy the connection handle properly. And then nothing else
happens because the connection has been destroyed.
|
| | |
| |
| |
| |
| | |
Not sure why these were here to begin with, since it does use the 'self'
argument and did so since they were added.
|
| | | |
|
| |\| |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This makes sure that a timer that returns 0 (or less) does not prevent
runtimers() from completing, as well as making sure a timer added with
zero timeout from within a timer does not run until the next tick.
Thanks tmolitor
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Partial backports of the following commits from trunk:
6c804b6b2ca2 net.http: Pass server name along for SNI (fixes #1408)
75d2874502c3 net.server_select: SNI support (#409)
9a905888b96c net.server_event: Add SNI support (#409)
adc0672b700e net.server_epoll: Add support for SNI (#409)
d4390c427a66 net.server: Handle server name (SNI) as extra argument
|
| | |
| |
| |
| |
| |
| | |
Some lines seem to have gotten the wrong indentation, possibly caused by
Meld which often ignores lines with only whitespace changes and leaves
their previous indentation.
|
| | |
| |
| |
| |
| |
| |
| | |
#1388)
The previous timer handling did not scale well and led to high CPU usage
with many connections (each with at least an read timeout).
|
| | |
| |
| |
| | |
It's an error, it should be logged at error level.
|
| | |
| |
| |
| |
| |
| | |
It's confusingly quiet otherwise, even with maximum verboseness.
Thanks perflyst
|
| | |
| |
| |
| |
| | |
Might improve (CPU) performance at the risk of triggering top level
errors.
|
| | |
| |
| |
| | |
This lets plugins handle errors in some custom way, should they wish to.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Unused since the move to util.indexedbheap in c8c3f2eba898
|
| | |
| |
| |
| |
| | |
Reduces the overhead of having both util.timer and the timer handling
here, since they are very similar and now API-compatible.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
socket
This adds an escape hatch where things like UNIX sockets can be added.
|
| | |
| |
| |
| | |
of unix sockets)
|
| | | |
|
| | |
| |
| |
| |
| | |
This would help pinpoint if a crash happens during the handshake, which
has occurred a few times, e.g. like https://github.com/brunoos/luasec/issues/75
|
| | |
| |
| |
| |
| |
| |
| | |
These are triggered all the time by random HTTPS connections, so they
are mostly just useless noise. When you actually do need them, you
probably have debug logging enabled too, since these messages are fairly
useless without more context.
|
| | |
| |
| |
| | |
This mirrors what server_event does.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Sometimes all these things just drown out the logs you are interested
in with low-level socket noise.
Enabled since it's still new and experimental.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Saves creating a string that'll be identical to buffer[1] anyways, as
well as a C function call. Depending on Lua version and length of the
string, this could be reusing an interned string, but a longer one would
probably be duplicated for no reason.
Having exactly one item in the buffer seems like it would be fairly
common, but I have not done an extensive study. If opportunistic writes
are enabled then it will be even more likely.
This special case could be optimized like this in table.concat but it
does not look like it is.
|
| | | |
|
| | |
| |
| |
| | |
Timer API of passing wallclock time remains
|
| | |
| |
| |
| |
| | |
Relative to current time instead of absolute time, in preparation for
switching to monotonic time.
|
| | |
| |
| |
| | |
This won't make sense if we switch to monotonic time
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In :onreadable, if there is still buffered incoming data after reading
from the socket (as indicated by the :dirty method, usually because
LuaSocket has an 8k buffer that's full but it read a smaller amount),
another attempt to read is scheduled via this :pausefor method. This is
also called from some other places where it would be pointless to read
because there shouldn't be any data.
In the delayed read case, this should report that the socket is "dirty".
If it reports that the socket is "clean" then the question is where
the buffer contents went?
If this doesn't get logged after the scheduled time (0.000001s by
default) then this would suggests a problem with timer or scheduling.
|
| | |
| |
| |
| | |
As with 0e1701197722
|
| | | |
|
| | |
| |
| |
| | |
As with 0e1701197722
|
| | | |
|
| | |
| |
| |
| | |
Writing what? The data that's been buffered for writing
|
| | |
| |
| |
| | |
Might come out of :getpeername different later but at least it's something.
|
| | |
| |
| |
| | |
Since they may have been unknown when the connection was created.
|
| | |
| |
| |
| |
| | |
These will sometimes return nil, "Transport not connected" but not throw
a hard error. This shouldn't be treated as success.
|
