The sends which were corrupted were manual sends - though there was another send in progress that was triggered by a file server script.
I can see the issues with ports - but I am unclear what mechanisms mIRC has in place to try to ensure that ports are not misconnected in this way.
1. There is no reason in principle that multiple remote IP addresses cannot connect with the same mIRC DCC port - this is a standard part of the TCP protocol. Tthe issue I think is that mIRC has no way of knowing the remote IP address associated with each DCC Send because that is not part of the ctcp PRIVMSGs / NOTICEs that are used by DCC SEND to create the direct connection. Assuming NOT passive DCC, I think that the DCC sender issues its IP and port in a DCC SEND CTCP message and then waits for a connection on that port - which could come from any IP address anywhere - and whatever IP address connects is assumed to be the receiving IRC client.
Is that understanding correct?
2. I guess that you can use the same DCC port for multiple simultaneous sends, but you would have to be sure that the connections were made in the correct order which would be impossible in practice. So it seems to me that you need as many port numbers open as pending connections - mIRC should not start a DCC send until it has a DCC port available that does not have a pending connection, and it should avoid offering the same port if the port has a pending connection.
3. The settings for DCC time-outs are also going to be critical to avoid mIRC believing that a connection has timed-out and then reusing the port for another connection - in order to avoid the second connection being connected to by the remote client trying to make the first connection.
4. I am unclear at what point a receiving mIRC makes the connection to the sending mIRC - does it do so at the earliest opportunity or does it wait until the user has clicked Accept in the pop-up dialog? If the latter, then that must increase the chances of a port being mis-connected.
5. Does mIRC use ports in an intelligent way i.e. trying to avoid using ports which have timed out and prioritising ports which have had successful connections to be used first?