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.
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.
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.
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.
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.
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.
LuaSocket TCP sockets have have both :connect and :setpeername, which
are the exact same function, however UDP sockets only have :setpeername.
Switching to :setpeername allows most of this code to be generic wrt
TCP/UDP.
