Here it is, the integration of the SlotAllocator is done! Well, that’s just the start actually. The connection preferencing and slot reservation algorithms are still to be implemented. The very simple old slot allocation policy is still in use, but I think it will do the job for a while. The important point about the SlotAllocator was to improve the design of the LocalPeer, which is still messy.

I think the design is better now because the Handshaker is responsible for the complete handshaking process. Before the LocalPeer was responsible for establishing a connection, managing the slots, freeing resources when a connection gets closed… This required more state checking to figure out exactly which kind of slot to free. That is exactly why I wanted to have the slots automatically freed! With the new design it seems that freeing the slots explicitly would be quite straightforward and bug-free, whereas the auto-freeing looks more like an overkill (though I would leave it for now).

As of this patch, the node caching will not always work correctly because I removed a call to NodeCache::addNode() in LocalPeer::handshakingFailed(). The reason is that I do not have the remote node address anymore (which one can get from the Connection* in ConnectionData) but only a ConnectionId. This ID is, by the way, also getting obsoleted and should be removed in one of the next rounds (it had something to do with the extrinsic states in ConnectionData).

While working on the SlotAllocator I found a bug in TcpConnection. Namely, in TcpConnection::connectTimeout() the fucntion QTcpSocket::disconnectFromHost() was called which effectively closes the socket. The thing was, however, that the connection is still in connecting state, and Qt has started a timer, which, when triggered, would abort the connection attempt. What disconnectFromHost() does not do is kill this timer! Under specific timing conditions one would get a segmentation fault. To avoid this, TcpConnection::abort() should be called instead.

With this changes Calitko randomly crashes under Windows. The only info I get from gdb is that freed memory is modified but nothing more. The call stack is corrupted. I will investigate this further.