mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: May 2005
Posts: 2
W
won Offline OP
Bowl of petunias
OP Offline
Bowl of petunias
W
Joined: May 2005
Posts: 2
copy/paste of the question I've asked on irc/google and other forums, all failed to get the right awnser sadly.

Quote:
"I want to change the roll-back buffer size for dcc transfers(usually only gets), its a feature that prevents files going corrupt when the transfer is stopped half-way. And a higher value is neccesary when transferring larger files because they take longer so the likelyhood of a interuption is bigger etc etc. anyway: ITs supposed to be a command you could enter in ALT-R + restart of mirc, but so far I didnt find the right command and where to put it exactley frown Thanks in advance"



::small disclaimer sort of thing::
I've come to learn that the default mIRC (recent versions, v6.16 for example) buffer memory size that buffers dcc transfers is 8KB in size.

Because I use mIRC's dcc feature to quickly send home-made videos to my friends in other continents I've ran into the following problem:

When Their download speed is limited, the transfers take longer. And in this time the chances of their connection getting resetted is bigger. And normally this isnt such a problem if it wasn't for the following:

The roll-back memory buffer for dcc transfers is only 8KB in size. I know for sure(ive came across it years ago through searching on google) that it was possible to change the default size of the roll-back buffer memory by adding a code + new-size in "Remote" (the ALT-R window).

Now that I've actually encountered problems because of this too small-a-default size, when I resume sending my vids. So now I really want to change it. I know it is possible but it seems NOONE knows how anymore smirk

Before I continue I would like to point out that:
Yes, i have used the search on this forum, in fact ive searched on every forum I could find related to mIRC
and secondly:
Yes, i've also asked on numerous mIRC supporting channels on irc

ALL TURNED ME DOWN, NOONE KNEW smirk so my hopes are set on you guys(maniac? smile

Again thanks in advance.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I do know it is possible. After all, the resume location is sent by the receiver and can be set to anything. I can't remember how anymore since 8k works just fine for me.

Note, however, that the script would need to be on the DOWNLOADER'S mIRC and not yours. The downloader sets the location to resume from... not the sender.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
You can do it in a "CTCP ^*:DCC SEND *:{" event however just as Riamus2 said, thats on the recievers end, his end would just need to truncate X bytes of the end of the file, then the resume would start at that shorter file size minus 8192 bytes (the standard rollback).

I think the problem might be minimized by you by setting "/FSEND off" from memory this allows your end to send the next packet before the previous one is acknowledged, why this would cause corruption at the recievers end im not sure, it might be it allowes a missing packet to desync the files. ie you send packets [1][2][3][4][5][6] they recieved [1][2][3][5][6] becuase they missed [4] but you kept sending so they thought [5] was [4] etc.
Fast sends is also menually (is that a word?) switch off able in /DCC SEND (see fast send tick box).

If this is the problem then roll back being larger is unlikley to fix the problem, since its a missing packet which might be anywhere.
Rollback was designed to remove the last packet only as this maybe faulty during the connection breach, looks like it was hardcoded to the largest packet size at some time, this being 8kb

* there is one last problem with using a script also, i just remebered, lets assume you removed 1meg, everytime someone sent the MESSAGE they were going to send the file it would remove 1meg, older mircs also removed the 8kb this way, now they wait for the file to actually be sent.
I demonstrated this flaw to a freind once, by repeatedly sending him the im going to send you the file message, over and over untell i deleted the whole file. This has thankfully been fixed smile

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
If you use a script, you want it to ONLY remove the bytes on a failed receive... not when you get a resume. That reduces the chance of problems. Of course, with a 1MB truncation, it is very easy to lose the entire file no matter what.

If people use 4096 (the best packet size for 99% of users), then the 8k truncation works just fine. Yes, 8k packets can be faster on some connections, but only if the sender and receiver can get 8k packets without packet loss. In most cases, the 4k packets are faster from what I've seen with the different sizes.

The only way to tell for sure is to test overall speeds (send a 10MB file to 10 people using 4k packets and check total time.... then repeat to the same 10 people using 8k packets). You need a decent file size for it to be accurate because speeds increase and decrease often and you need to see overall speeds.


Invision Support
#Invision on irc.irchighway.net
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
Oh you mean cut the file back when it fails once rather than on any resume, much cleverer (cleverer a word?) idea. The 1 mb was just a pulled from the air figure.
I personally have never flound a problem with files that are large i have downloaded and resumed, I have a $CRC list of them and have downloaded some large ones and they match by $crc(filename) exactly when i recieve them from the orginals and even when i copy one to a cdr i have compared them later and they match (you would hope they do be detrected as faulty being zips), admittedly these are all coming from the same source (a client i keep up with them incase i cant get on the ftp with em), so maybe its sender related, i dont have that fastsend on, i think my packets are at 4kb as well by the way, no idea why tho.

Joined: Oct 2004
Posts: 8,330
Hoopy frood
Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I use fastsend and only time anyone has had a problem getting any file from me has been modem users... and even then, it's not often. And I haven't had issues myself except back when using a modem. I think I'd suggest the rollback script for modem users to be something like 16k and leave it at 8k for broadband users.

I really don't remember a whole lot about modems, but I think the way modems handle data, a disconnect on their side can cause a loss of more than one or two packets (causing the corrupted file).


Invision Support
#Invision on irc.irchighway.net
Joined: May 2005
Posts: 2
W
won Offline OP
Bowl of petunias
OP Offline
Bowl of petunias
W
Joined: May 2005
Posts: 2
I fear I didn't make myself clear enough. But first off thanks for the many replies.

I am on the receiving end. I need a higher roll-back buffer on my side. One that truncates the file to a shorter filesize on disconnect. ie. I received 1.08 MB, the transfer gets interupted and then my own client rolls back 1 MB to 0.08 MB or the atlernative route would be i would receive 2.08 MB but my client will only except 1.08 untill ive got another 1 MB passed 2.08, so the actual sent data would be 3.08 and my client would show up 2.08 (1MB roll-back).

It comes down to the same thing, something you can set in Remote but I dont know what.

Also the suggested packet size of 4096 Kbits from the supportchannel person: do you mean the packetsize set at your NIC settings for data transmissions or something you could set in mirc ?


Link Copied to Clipboard