Forums Bug Reports DCC resume

Tested with 7.48, but the behavior seems to be the same going back well into 6.xx

When requesting resume-get of an incoming file, mIRC requests an offset which replaces the last 8192 bytes of the receiver's partial file. I assume this is because of the possibility of the last-received full packet to be garbled, so back when the largest packetsize was 8192, mIRC defaulted to asking for re-sending the last 8kb. However, I'm wondering if this number should be either increased since 6.33 started allowing packetsizes as large as 65536, or eliminated since there doesn't appear to be a huge problem of damaged files from people using larger packetsize.

#1 bug: no visual feedback to sender or receiver when resuming smaller file on top of larger file.

1. Have someone take any 2 files, and copy the larger to filename test.txt and send test.txt to you.
2. Then have them copy the smaller of the 2 files to filename test.txt and send test.txt to you.
3. mIRC correctly ignores an auto-resume attempt of a smaller file even if it's 1 byte smaller. But shouldn't the receiving mIRC display a rejecting message in the status window as well as do something besides ignoring the sending mIRC? The receiving mIRC shows the notice "-sender- DCC Send filename (ip)" and it does trigger the "ctcp *:DCC SEND *:" event, but there's no visual indicator to the receiver to explain why nothing's happening, and the sender gets no feedback why their send fails, just getting a send-window that hangs open until it times out.

#2 bug: mIRC requests resume-send of filesize 1-8192 at offset zero instead of just requesting normal request as if receiver didn't have the incoming filename.

If incoming file exists in download folder with filesize zero, mIRC accepts the file without asking for it to be resumed. However, if the filesize is 1-8192, the receiving mIRC requests a resume offset of 0. Wouldn't it be preferable to accept the incoming file the way it normally does when there's no file? This saves the trouble of extra handshaking in making the resume-get request. This would be a help to people who are unable to dcc-send because their system is remapping ports behind mIRC's back, causing the send to be received as if it's coming from a different port than mIRC is sending from. I know it's possible to script within "ctcp *:DCC SEND *:" to delete a small file so the incoming file won't resume at offset zero, but that assumes the future send will be successful, and also requires extra checking to make sure the small file isn't because someone else is in the beginning stages of sending something under the same filename.

#3 bug: When incoming file is exact same size as receiver's existing file, mIRC requests the last 8kb of the file be sent instead of ignoring/rejecting same as #1 above.

When the incoming file is the exact same size as the existing file in the download folder, mIRC requests the file be resumed at max(0, $filesize -8192), causing a re-send of the file's final 8kb. Shouldn't the behavior of (incoming size == existing size) be the same as when (incoming size < existing size)? While there might be an argument for repeating 8kb of a smaller partial file when resuming, I can't see the benefit from repeating the last few kb when the filesizes are identical, unless there are cases where the receiver receives the full filesize but somehow decides the file received was incomplete.

Related solution/feature request: Ability to configure mIRC to change re-sent bytes requested to either zero or larger than 8192.

I'm assuming there's not currently a way for the receiver's mIRC to know the packetsize the sender's mIRC is using, until it inspects the packets that arrive - and from past experience I've seen transferred bytes increasing by amounts smaller than by PACKETSIZE chunks, so it looks like packet sizes may sometimes get negotiated down as the transfer continues.

Perhaps there could be something in mIRC-options/DCC to configure your own mIRC to determine how many bytes to repeat for all resume-gets, with the default number being the current 8192. This keeps the current behavior the same, while allowing people to disable destroying the last 8kb of a not-corrupt file because someone happens to send a larger but different image wallpaper.jpg or .ZIP than the file you have in your download folder. Just like mIRC parallels the mIRC-options menu in allowing packet size changes by a script with "/dcc packetsize 65536", a new command could be something like "/dcc resend 0" to re-set the RESUME protocol to ask for 0 bytes of the receiver's filesize be re-sent.

Indeed, I have not touched the DCC-related code for a long time mainly because it has been stable and reliable.


The DCC protocol has no method of informing the sender of this. As for the receiver, when I test this here, it tells me that a larger file exists than the one being sent to me and gives me the option to overwrite/cancel.


If the file exists and has content, mIRC should ask you if you want to resume it.


This was implemented a long, long time ago due to the common occurrence of the last packet of a file being corrupted.

The development process for DCC resume went through many years of testing, feedback, and real-world use before it stabilized. So I can understand that some of the design decisions may not be clear. However, unless there is an actual bug in the code that prevents DCC resume from working, I would rather not make any changes to it.

Thanks for your reply. I can understand reluctance to alter dcc. I'll make a related feature request post, which your reply made me think of, which hopefully falls far enough outside altering the dcc protocol.



It looks like you're referring to the dialog the receiver gets when setting 'if file exists' to 'ask'. I'd forgotten to mention that I was describing how things are when /sreq is set to auto-get files and 'if file exists' is set to 'resume'. The 'ask' dialog doesn't always tell by filesize that the existing is larger than incoming. Though, you can infer the incoming is smaller by seeing that the 'resume' button is disabled. If the 2 sizes displayed are the same number, you don't know whether they're both exactly the same size, or if the incoming file is slightly larger but both files round to the same 1/10th kb size.

What I was trying to say is that when mIRC is set to auto-get and automatically resume incoming files, and someone sends a filename with size smaller than the receiver's existing file, the receiver sees the notice

-sender- DCC Send versions.txt (sender's IP)

and the CTCP DCC SEND event gets triggered, but if the receiver doesn't have a script which intercepts the CTCP event, all they see is the above notice and then nothing happens.

When I mentioned no message about the invalid incoming DCC, I was thinking of how the sender gets a warning in the status window when the receiver requests a resume-get using the wrong port number or waits too long to accept the resume-get.

DCC Resume from sender rejected (invalid parameters)

During auto-get-auto-resume settings, by ignoring the incoming file once the receiver's mIRC discovers it's smaller than their own existing file, the receiving mIRC is treating the DCC SEND as if it contains an invalid size parameter, it's just not displaying a message to themselves like the sender sees when they see the receiver reply uses the wrong resume-port.



In most cases I agree, however when the filesize is 1-8192, mIRC's resume-get at offset zero is not resuming any content, it's wiping out the entire content and introduces RESUME into the situation where it doesn't benefit the receiver, and can inconvenience both sides when the sender's router is changing ports so the receiver's resume-get message responds with an invalid port number.

It seems it would be preferable for the receiving mIRC to always treat the 'if-file-exists' settings as if it's 'overwrite' if the incoming filesize is 1-8192, because that's the same effect as a resume-get at offset zero.

It's creating the same effect as 'overwrite' except it's introducing RESUME into the situation, which some people can't do because of something their ISP is doing. For years I had problems because U-Verse intermittently changed the port number between when my mIRC sends the file and the receiver gets the file. This allowed me to successfully DCC SEND except when the receiver asked for a resume-get, which failed because they saw the file coming in from a different port than it was actually sent from. When resuming at offset zero, nobody benefits from any preserved content, and it appears that mIRC doesn't delete my existing 1-byte file if the incoming overwrite fails to begin a connect because they're unable to dcc send.



I wasn't aware that it was common for the file's last packet to be corrupted while still letting both sides think 100% of the file has transferred. It's common for jpg and zip files to be in the situation where a slightly smaller file in the download folder is resumed by an unrelated-but-larger file that happened to have the same filename. And, in the rare cases where I've downloaded a file that turned out corrupted, I can't remember a case where I found that the corruption was in the final packet. The corruption was either somewhere in the middle of the transfer, or was caused by the sender's file already being corrupted before the transfer. Maybe I've just been lucky.

Since people are now using packet sizes larger than 8kb, I was hoping that the lack of an epidemic of data corruptions while mIRC resumes only 8kb of a 64kb packet meant that replacing the final 8kb of resume-get files or resuming same-size files could be something people could tell their mIRC to opt out of, or if they do have problems, they could increase the portion of the file they wish to replace during the resume-get.