| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| | |
A Direct TLS connection (eg HTTPS) gets turned into a LuaSec handle
before the :updatenames call done in the :connect method. LuaSec does
not expose the :getpeername and :getsockname methods, so the addresses
remain obscured, making debugging trickier since the actual IP addrerss
connected to does not show up.
|
| |
| |
| |
| | |
It was weird that it said "Prepared to start TLS" before "Client .. created"
|
| | |
|
| |
| |
| |
| |
| | |
The similar logging in mod_c2s and mod_s2s does not cover all
connections, like HTTPS or other Direct TLS ports.
|
| | |
|