Branch: refs/heads/master
Home: https://github.com/ngircd/ngircd
Commit: 629a45ee0f4469729f6a9c22a983000fcc39fe61
https://github.com/ngircd/ngircd/commit/629a45ee0f4469729f6a9c22a983000fcc3…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-04 (Mon, 04 May 2020)
Changed paths:
M src/ngircd/conn.c
M src/ngircd/defines.h
Log Message:
-----------
Revert "Increase read buffer size for server connections"
This reverts commit c6e3c13f27744971fcb1d2de4e561d3bcdaa5aed.
This sounded like the right approach at first, but I'm not that sure
that it really makes sense to have different sizes of read buffers: the
per-connection read buffer only needs to keep data that is needed to
parse one full command, be it plain text, encrypted and/or compressed.
Then ngIRCd should handle this one command, move leftover data to the
beginning of the buffer and read the next chunk from the network that is
missing to get the next complete command (512 bytes at max).
So I revert this for now and try to fix the logic in Read_Request(),
which is broken nevertheless, as it results in servers becoming
disconnected during "server burst" when "big" lists are transferred.
Commit: 9f05f5ee61d23292d55edef09439c38936b86037
https://github.com/ngircd/ngircd/commit/9f05f5ee61d23292d55edef09439c38936b…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-04 (Mon, 04 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Read_Request(): Clean up code and add some more comments
No functional changes.
Commit: 54fac576030d7aaf8bce4a982c880fe18680741e
https://github.com/ngircd/ngircd/commit/54fac576030d7aaf8bce4a982c880fe1868…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-04 (Mon, 04 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Handle commands in the read buffer before reading more data
If there are more bytes in the read buffer already than a single valid
IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those
command(s) to be handled first and don't try to read even more data from
the network (which most probably would overflow the read buffer of this
connection soon).
Commit: 387a29a7fdbf00f5d792ba1450c608db8670308a
https://github.com/ngircd/ngircd/commit/387a29a7fdbf00f5d792ba1450c608db867…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-04 (Mon, 04 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Don't wait for the network when read buffers possibly hold commands
There is no point in waiting up to one second for the network receiving
new data when there is still a read buffer holding at least one command;
we shouldn't waste time but handle it immediately!
Compare: https://github.com/ngircd/ngircd/compare/8d414b079c1b...387a29a7fdbf
Branch: refs/heads/proposed/read-buffer-fixes
Home: https://github.com/ngircd/ngircd
Commit: 41b8b75f6dcbf5c15f414cdca1aec7a784aa6ca1
https://github.com/ngircd/ngircd/commit/41b8b75f6dcbf5c15f414cdca1aec7a784a…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conn.c
M src/ngircd/defines.h
Log Message:
-----------
Revert "Increase read buffer size for server connections"
This reverts commit c6e3c13f27744971fcb1d2de4e561d3bcdaa5aed.
This sounded like the right approach at first, but I'm not that sure
that it really makes sense to have different sizes of read buffers: the
per-connection read buffer only needs to keep data that is needed to
parse one full command, be it plain text, encrypted and/or compressed.
Then ngIRCd should handle this one command, move leftover data to the
beginning of the buffer and read the next chunk from the network that is
missing to get the next complete command (512 bytes at max).
So I revert this for now and try to fix the logic in Read_Request(),
which is broken nevertheless, as it results in servers becoming
disconnected during "server burst" when "big" lists are transferred.
Commit: f5da13caf4d2ee45a8a6c32a09d60fc4e2c027b2
https://github.com/ngircd/ngircd/commit/f5da13caf4d2ee45a8a6c32a09d60fc4e2c…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Read_Request(): Clean up code and add some more comments
No functional changes.
Commit: edb666693a8117c3f5f2ef77a9461cec0974876d
https://github.com/ngircd/ngircd/commit/edb666693a8117c3f5f2ef77a9461cec097…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Handle commands in the read buffer before reading more data
If there are more bytes in the read buffer already than a single valid
IRC command can get long (513 bytes, COMMAND_LEN), wait for this/those
command(s) to be handled first and don't try to read even more data from
the network (which most probably would overflow the read buffer of this
connection soon).
Commit: 5c1c5ecacbe8d8a5cdac212985619433a86850bb
https://github.com/ngircd/ngircd/commit/5c1c5ecacbe8d8a5cdac212985619433a86…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conn.c
Log Message:
-----------
Don't wait for the network when read buffers possibly hold commands
There is no point in waiting up to one second for the network receiving
new data when there is still a read buffer holding at least one command;
we shouldn't waste time but handle it immediately!
Compare: https://github.com/ngircd/ngircd/compare/41b8b75f6dcb%5E...5c1c5ecacbe8
Branch: refs/heads/master
Home: https://github.com/ngircd/ngircd
Commit: 8a37695bf363a7cc2eb4bf3d17ff651f92cab253
https://github.com/ngircd/ngircd/commit/8a37695bf363a7cc2eb4bf3d17ff651f92c…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M contrib/nglog.sh
Log Message:
-----------
contrib/nglog.sh: Looks like GNU awk (gawk) is needed ...
Commit: 8d414b079c1b4b0b8c88c8ab5cf4b27bf0942752
https://github.com/ngircd/ngircd/commit/8d414b079c1b4b0b8c88c8ab5cf4b27bf09…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conf.c
Log Message:
-----------
Correctly use Config_Error() instead of Log() in Read_Config()
The name of the Config_Error() function is misleading: it is not only
used to show configuraton errors, but all messages shown during normal
operation as well as for "config testing": it takes care of the correct
formatting of the messages (syslog, forground logging, config testing).
This fixes commit bb1d014abad8.
Compare: https://github.com/ngircd/ngircd/compare/71e9bb1ca637...8d414b079c1b
Branch: refs/heads/master
Home: https://github.com/ngircd/ngircd
Commit: 79a917f954bef8089967786bd3597a6e5ff5c336
https://github.com/ngircd/ngircd/commit/79a917f954bef8089967786bd3597a6e5ff…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/conn-func.c
Log Message:
-----------
Set the "last data" time to "last ping" time when updating the latter
This is required because the PING can be received quite a bit earlier
than it is actually handled, for example during "server burst" or other
heavy operations:
So the times won't match and PING-PONG logic would become garbled,
because we test for "last ping > last data" to determine if a PING
already was sent or not.
Commit: 0dc692b1f77a147d9d5bf63c1eb7889a239420b4
https://github.com/ngircd/ngircd/commit/0dc692b1f77a147d9d5bf63c1eb7889a239…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M src/ngircd/irc-oper.c
Log Message:
-----------
Log G-/K-Line changes only when not initiated by a server
This prevents the log from becomming spammed during "net bursts".
Commit: 71e9bb1ca6378d517b491db54c42e992e0707ed1
https://github.com/ngircd/ngircd/commit/71e9bb1ca6378d517b491db54c42e992e07…
Author: Alexander Barton <alex(a)barton.de>
Date: 2020-05-03 (Sun, 03 May 2020)
Changed paths:
M .travis.yml
Log Message:
-----------
Update Travis-CI configuration, "sudo" is depreacted
Compare: https://github.com/ngircd/ngircd/compare/42e8654d7b04...71e9bb1ca637