Archive: Inetload bandwidth and latency calculation
Inetload bandwidth and latency calculation
this is for Takhir. i'm wondering if you eventually plan in the future to add bandwidth, latency and speed calculation.
IMO knowing in advance if those three parameters are good enough to download big files could be usefull at script level (i.e. if any of those parms are not good you can decide to delay script execution later or to abort as well).
thanks.
You can calculate average speed using download start/finish times (time() or GetTickCount() calls using System plug-in) and received file size.
Current InetLoad implementation is "modal", i.e. it returns control to installer when download finished or failed. And my big :) plan is to add modeless switch to perform background downloads during installation. But I have not time for this right now. And small improvement (soon) - /NOCANCEL switch (while I guess this is not safe). And I still hope to finish /POST mode tests.
NSIS plug-ins have access to $ variables, so InetLoad can update, for example, $9 with current average speed value, but in "modal" mode this have not sense - script execution will be continued after plug-in have exited only.
Thanks&thoughts
thanks Takhir: i'll see if GetTickCount can fit to my needs.
I also have in mind to convert to nsis a code snipplet i wrote some time ago in a different language to calculate latency and speed; just remind now. i'll post in case of interest.
About /nocancel that was my need as you know i'm totally with you on saying it can be unsafe. However, you may know sometimes it's not a matter of choosing the best solution (when developing network solutions) but choose the best option with the minor risk... Especially when you've to deal with users (many users) whose actions are often really unpredictable. In my case , for example, with /nocancel i'm quite sure users don't break download of important sw updates, but at the same time it's unsafe even dangerous not to allow stop download in certain cases (i.e. when network speed very slow).
One possible solution could be to trap a possible Cancel and present the user a Y/N messagebox asking wheter continue or not: if users says 'yes: continue downloading' then restart inetload with /resume flag. Is this possible IYO ?
thanks.
Thanks, jsbach, this is possible, but we need to remember - it's logic should be intelligible for developers in all situations (like silent installs - default result for plug-in's message box). Any case I'll include simple /nocancel to the next build.