mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
Had someone send me two files - let's call them FILEA (x bytes) and FILEB (y bytes). User was already sending another file FILEC (x bytes) to someone else.

FILEA was sent to me first. I received x bytes but they were from FILEC - this happened to be a zip file but I only got part of it - but I could see that it was a different file.

FILEB was sent to me next. I received y bytes but from FILEA. I had the user set MAX SENDS to 1 and they were then able to send me the files correctly.

I am on 7.58 - other user is on 7.27 (which is pretty old).

Last edited by Protopia; 20/01/20 08:34 PM.
Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320

Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
Other user is running a file serving script (OmenServer) which I believe uses 3x mIRC specific DLLs. Not sure whether this could cause this sort of corruption. As far as I know the DLLs are used to provide file searching functionality and do not have any functionality to work with DCC SEND.

I do know the DLL author (though he wrote the DLLs perhaps a decade ago), so I may be able to get some help with debugging this if we think it is a result of DLL causing this.

Joined: Dec 2002
Posts: 5,482
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,482
Thanks for your bug report. I have not been able to reproduce this so far. If you can find a method of reproducing this in a clean copy of mIRC, that would be best. If a script is being used, you would indeed need to debug that script to see what is going on.

Joined: Dec 2002
Posts: 5,482
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,482

It has been a long time since the DCC protocol was last discussed, so if you were there during those discussions, please correct me if I am wrong. As I remember it, the issue linked to above is actually possible with DCC Send. DCC Send simply allocates a port number to which a receiver can connect to receive a transfer. This means that if a send fails/times out/is cancelled and its port is allocated to another send, the receiver can connect to that port thinking that it is related to a different send request. If the DCC Send protocol allowed for the first few bytes of the transfer to include identifying information, that would prevent an issue like this but it was not so designed.

Joined: Aug 2003
Posts: 320
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 320
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?


Link Copied to Clipboard