Emerson, Am 03.01.19 um 16:19 schrieb Emerson Gomes: > This works fine most of the time, but every now and then, when I check the > stick table contents, one or more IPs show up with an absurd number of > cunn_cur - Often around 4 Billion entries - A number very close to > the 32-bit unsigned int data type limit. >
That looks like an integer underflow and a limitation of the peer protocol. If I understand it correctly the peer protocol always sends an absolute value to it's peers, instead of a relative modification operation such as "value++". While I'm not able to cause a connection to be decremented twice I am able to cause some connections to never be decremented because of a race condition: - Connect to peer A (A=1, B=0) - Peer A sends 1 to B (A=1, B=1) - Connect to peer B (A=1, B=2) - Peer B sends 2 to A (A=2, B=2) - Kill both connections at the same time (A=1, B=1) - Peer A sends 1 to B (A=1, B=1) - Peer B sends 1 to A (A=1, B=1) There are no connections remaining, but both peers believe that there still is one connection. To cause the underflow you are seeing I imagine the following happens, but I don't manage to get the timing right. - Connect to peer A (A=1, B=0) - Peer A sends 1 to B (A=1, B=1) - Kill connection to A (A=0, B=1) - Connect to peer B (A=0, B=2) - Peer A sends 0 to B (A=0, B=0) - Peer B sends 0/2 to A (A=?, B=0) - Kill connection to B (A=?, B=-1) - Peer B sends -1 to A (A=-1, B=-1) An easy fix would probably be skipping the decrement if the value is already 0. The counter will be off either way, though. Best regards Tim Düsterhus
