'Losing' sockets in Qt torrent example / QTcpServer

[Kumosan]

Hi, I have a strange problem with the Trolltech examples/network/torrent code. I took the code to build my own bittorrent client with it. But something is not right either with the code, with QTcpServer or with my computer. I doubt the last.

When the program runs for a while, sockets in close_wait states pile up. Sooner or later I get a 'too many files open' error message and the program stops.

Now I logged all addresses/ports of all incoming and outgoing peers. These are either the connections I initiate with the peer list I get from the tracker, or incoming connections, which are initiated by other peers.

The problem is I never see the close_wait sockets in my logs. In my program they simply don't exist (the address/port pair).

How likely is it that this is some sort of race bug in QTcpServer? It accepts a connection, but somehow 'swallows' the notification sometimes. My program never sees those swallowed connections, sends no data and the peer closes the connection on his side. The socket remains in close_wait forever and I cannot close it manually since it is unreachable for me.


Found the bug. QTcpServer is ok.

[wysota]

What was the problem?

[Bitto]

This bug was recently reported, and will be fixed in the next Qt release. Basically there's a bug in torrentserver.cpp, swap the two ifs (if (socket.setSocketDescriptor()) should go before the if (canAddConnection)).

The bug is that the server implementation in this example doesn't close the sockets if it doesn't have room for it. So it leaks sockets until it can no longer create more.