Is there any way to?

Sure there is .. ask the sender to limit their cps

I was thinking more along the lines of 'on the fly', so if someone was to send me a large file and i needed to slow it down a bit & they're not @ their terminal, then i could do it from my end. Although if thats the only way then i guess so be it, would be nice if you could though. Anyway, thanks for reply 'n' all.

Unfortunately, thats not how bandwidth throttling works. You can only control the speed of the traffic that you send. This isn't a limitation specific to mIRC, its how TCP works.

-chris

can always script in a way via SCRIPTs of course.. so pl can send u a msg n have i slow down accordingly. who knows it may become an irc standard?

Would certainly keep users that little bit happier when it comes to choice.

DCC does not work in the traditional way of tcp transfers. It receives a chunk of data, then responds to the sender, and the sender continues with the next chunk. Some clients will not even send more than the first packet, a couple of Kbytes, unless they receive the proper response from the recepient during a DCC (other less-conformed clients just dump it like any other tcp xfer). Really I don't know any reason why mIRC couldn't have a threshhold on incoming transfers, it's just not there (yet). I could be wrong though.

um .. maybe because it was designed as a chat client with limited filesharing capabilities, not a file transferring client with chat capabilities?

You act like it would take more than a minute or two to implement. There are real reasons to take into consideration.

All you do is set a timer that checks how much it has received since the last timer interval. If it's less than the set "download speed limit", it sends the dcc "ack" so the sender continues the xfer.

Mind you, this fix would only work with clients that follow the standards for the dcc protocol (choking the send until it receives an ack) and it would not be a 100% precise slowdown since some people set their DCC packetsize differently. Perhaps the confusion over why it may or may not be working at times is the reason for not adding it.

It may also be possible to do the checking on the data-receiving level, but I am not sure how safe that would be since there might be an excessive transfer overhead.

I don't think it's a matter of how long or easy it would be to implement, it's the principal that mIRC is not a file sharing program. The file sharing capabilities of mIRC suffice for 98% of people who use it legitimately, and unless there's a bug that's affecting the DCC feature or indeed any other part of Windows or mIRC itself, there's little point in developing it. Even harder to do this whilst at the time discouraging illegal/mass file trading.

My 2 cents.

Regards,