Branch: refs/heads/proposed/read-buffer-fixes Home: https://github.com/ngircd/ngircd Commit: 41b8b75f6dcbf5c15f414cdca1aec7a784aa6ca1 https://github.com/ngircd/ngircd/commit/41b8b75f6dcbf5c15f414cdca1aec7a784aa... Author: Alexander Barton <alex@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/f5da13caf4d2ee45a8a6c32a09d60fc4e2c0... Author: Alexander Barton <alex@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/edb666693a8117c3f5f2ef77a9461cec0974... Author: Alexander Barton <alex@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/5c1c5ecacbe8d8a5cdac212985619433a868... Author: Alexander Barton <alex@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