| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
current state
Reduces needless duplication of work and log messages..
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
mod_proxy65 calls link twice, once for each direction. This would
overwrite the listeners with one that has the previous listeners as
metatable.__index, but none of the others.
This takes advantage of 94c584d67533 to improve this.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
To allow referencing connections by id instead of tostring form
|
| | |
|
| |
| |
| |
| |
| |
| | |
Code added in 75d2874502c3, 9a905888b96c and adc0672b700e uses this field.
See #409 and #1408
|
| |
| |
| |
| |
| | |
This lets code attach some extra data to be attached to client
connections.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This tries to flush data to the underlying sockets when receiving
writes. This should lead to fewer timer objects being around. On the
other hand, this leads to more and smaller writes which may translate to
more TCP/IP packets being sent, depending on how the kernel handles
this. This trades throughput for lower latency.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Prevents error from attempting to index nil conn on such failure.
Silences luacheck warning about the 'err' variable being unused
|
| |
| |
| |
| |
| |
| |
| | |
listener error
Sometimes such errors leave sessions in an inconsistent state, so it
might be better to close them early.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a chunk of data has been received that is larger than the amount read
at a time, then the connection is paused for a short time after which it
tries to read some more. If, after that, there is still more data to
read, it should do the same thing. However, because the "want read" flag
is removed and was restored after the delayed reading, it would not
schedule another delayed read.
|
|\| |
|
| |
| |
| |
| |
| |
| | |
This should prevent #1333 in cases where LuaSockets buffer is "dirty",
i.e. contains more data after a read, where it gets resumed with a
short delay.
|
| |
| |
| |
| |
| |
| |
| | |
callbacks (fixes #1333)
This prevents the :set(true) call from resuming a connection that was
paused in the onincoming callback.
|
| | |
|