DCC resume - 24/04/17 04:28 PM
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.
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.