Branch: refs/heads/master Home: https://github.com/ngircd/ngircd Commit: 629a45ee0f4469729f6a9c22a983000fcc39fe61 https://github.com/ngircd/ngircd/commit/629a45ee0f4469729f6a9c22a983000fcc39... Author: Alexander Barton <alex@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/9f05f5ee61d23292d55edef09439c38936b8... Author: Alexander Barton <alex@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/54fac576030d7aaf8bce4a982c880fe18680... Author: Alexander Barton <alex@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/387a29a7fdbf00f5d792ba1450c608db8670... Author: Alexander Barton <alex@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