mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
Would it be possible to extend the mIRC Resume Protocol as described at https://www.mirc.com/help/html/index.html?dcc_resume_protocol.html to include (in a backwards compatible way) an MD5 hash of the part of the file already received in order that mIRC can verify that the existing part received is uncorrupted before attempting to resume the file from where it got to?

Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
it's difficult to change protocols without breaking backwards compatibility unless the protocol is specifically created to allow future changes in a way which notifies the older clients that its safe to ignore the new thing they don't understand.

Do you know of any such protocol? The closest I could think of is that newer clients supposedly ignore the filename because they depend on the port number, so the md5 could masquerade as that. Scripts which handle DCC RESUME have no way to know what that port number is, so if the filename isn't there, they don't know which open send to that nick is being resumed.

Also, since mIRC is resume-sending prior to the end-of-file for the receiver's partial file, neither the sender or receiver is currently setup to handle hashing a partial file, so that would need to be added somewhere into the md5 handler.

Joined: Aug 2003
Posts: 319
P
Pan-dimensional mouse
OP Offline
Pan-dimensional mouse
P
Joined: Aug 2003
Posts: 319
I am thinking about having additional fields in the RESUME and ACCEPT CTCPs.

So, for example rather than "/ctcp server-nick DCC RESUME filename port position" a mIRC version supporting MD5 would send "/ctcp server-nick DCC RESUME filename port position-x md5-of-first-x-bytes".

If the mIRC receiving this didn't support MD5 it would ignore the additional field and send the existing "/ctcp client-nick DCC ACCEPT filename port position".

If the mIRC receiving the RESUME did support MD5 it would check that the MD5 matched and if so send "/ctcp client-nick DCC ACCEPT filename port position md5-of-first-x-bytes". If the MD5 didn't match it would instead send "/ctcp client-nick ACCEPT filename port 0".

I believe that this would be backwards compatible, though you are much better positioned to judge whether this is the case.

Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
What you suggest by tacking fields onto the end probably doesn't work because of mIRC's support for filenames having spaces. Because the "file name" can potentially use more than 1 token if the filename has spaces in it and the 'fill spaces' option is unchecked. A script probably should be finding the filename by parsing for a token ending with a quote, but this works with the existing protocol too, and is much faster:

//var %a DCC RESUME "name with spaces.jpg" 12345 654321 | echo -a port $gettok(%a,-2,32) offset $gettok(%a,-1,32) filename $gettok(%a,3--3,32)

Scripts will be broken if you tack on extra fields, and I don't know how older/existing clients would behave if they encountered unknown fields.


Link Copied to Clipboard