Why not keep the update cycle time based, but in addition,
Serv_spy will upload the new info, if the server changes.
Example: (update every 60min)
start
0 min -> upload
32min -> the connection to server A is lost and
reconnected to server B. -> upload -> countdowntimer 60
resets
on 92min (32+60) -> reupload same server info -> countdown
60 min.
This will be very reliable information with low use of
bandwitdh. Maybe to increase relability even more, time
cycles could be max to 1 or 2 hours.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess it would be difficult to notice that the server connection was lost
and edonkey had to reconnect. sadly the donkey does not send
notification messages to the general public :)
if servspy only
generates/sends a new image on a serverchange and the update
time is pretty low (5min) things should be pretty up to date.
noja,
if you've not already fixed this, I can implement the necessary changes
later... post a note in the dev forum, I don't get emails about changes in
this tracker thingie *frown*
-rtf
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Nutrino your idea is pretty good but could cause a lot of updates
since edonkey sometimes changes server very often.
Another approach would be to specify a minimum update interval,
meaning that updates will never happen if this interval isn't reached.
If the server isn't changed after the passing of this minimum interval
updates would be postponed until the next minimum interval or until
the forced update.
An example:
Minimum update 15 mins.
Forced update 60 mins
Update at 0 mins
at 15 mins a check is made but there is no serverchange.
at 23 mins the server changes
at 30 mins a check is made and it updates
at 90 mins a check is made no serverchange but reached forced
update, so an update happens.
I'm not really sure which of these three suggestions are best. :)
Your input is appreciated.
By the way there is another way to implement my idea, that involves
frequent checks, probably better:
Minimum update 15 mins.
Forced update 60 mins
Update at 0 mins
at 23 mins the server changes, an update happens because it is
beyond the minimum update.
at 30 minutes server changes, but no update because only 7 mins
have passed.
at 38 minutes update happens 23+15=38
at 98 mins (60+38) no server change, but reached forced update.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Noja, you're right. Sometimes edonkey changes servers
constantly, so you might want to filter that out. A
min_upload_timer, every 10-15 minutes will do that. Check it
every 10-15 minutes, if server_IP is changed then upload.
(and reset force_update_time). The goal, to get information
as accurate as possible with minimum use of bandwidth will
be met.
Example:
Minimum update 10 min.
Forced update 60 min
In this way the server state will be check every 10 minutes
and only uploaded when the server is changed. The
information will be 'refreshed every 1 hour' if no server change
occurred.
000 connect to server - upload - forced_update_counter reset
to 60min.
010 min no server_change
020 min no change
030 min server_change - upload - Forced_update_counter
reset to 60min.
040 min server_change - upload - Forced_update_counter
reset to 60min.
060 min no change
070 min no change
080 min no change
090 min no change
100 min no change, forced update counter reaches 0 -
upload -
Anywhere between 20-29 min. the server changed, and
between 30-39 min. its changed again (maybe even multiple
times) but resulting in only two updates. In this way
information will be accurate to a period of 10 min, but upload
frequency is only 3 times in 100 minutes.
Maybe I would be an idea to log this information in a log file,
so the reliably of servers can be measured?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=550724
Why not keep the update cycle time based, but in addition,
Serv_spy will upload the new info, if the server changes.
Example: (update every 60min)
start
0 min -> upload
32min -> the connection to server A is lost and
reconnected to server B. -> upload -> countdowntimer 60
resets
on 92min (32+60) -> reupload same server info -> countdown
60 min.
This will be very reliable information with low use of
bandwitdh. Maybe to increase relability even more, time
cycles could be max to 1 or 2 hours.
Logged In: YES
user_id=550684
I guess it would be difficult to notice that the server connection was lost
and edonkey had to reconnect. sadly the donkey does not send
notification messages to the general public :)
if servspy only
generates/sends a new image on a serverchange and the update
time is pretty low (5min) things should be pretty up to date.
noja,
if you've not already fixed this, I can implement the necessary changes
later... post a note in the dev forum, I don't get emails about changes in
this tracker thingie *frown*
-rtf
Logged In: YES
user_id=544193
Nutrino your idea is pretty good but could cause a lot of updates
since edonkey sometimes changes server very often.
Another approach would be to specify a minimum update interval,
meaning that updates will never happen if this interval isn't reached.
If the server isn't changed after the passing of this minimum interval
updates would be postponed until the next minimum interval or until
the forced update.
An example:
Minimum update 15 mins.
Forced update 60 mins
Update at 0 mins
at 15 mins a check is made but there is no serverchange.
at 23 mins the server changes
at 30 mins a check is made and it updates
at 90 mins a check is made no serverchange but reached forced
update, so an update happens.
I'm not really sure which of these three suggestions are best. :)
Your input is appreciated.
By the way there is another way to implement my idea, that involves
frequent checks, probably better:
Minimum update 15 mins.
Forced update 60 mins
Update at 0 mins
at 23 mins the server changes, an update happens because it is
beyond the minimum update.
at 30 minutes server changes, but no update because only 7 mins
have passed.
at 38 minutes update happens 23+15=38
at 98 mins (60+38) no server change, but reached forced update.
Logged In: YES
user_id=550724
Noja, you're right. Sometimes edonkey changes servers
constantly, so you might want to filter that out. A
min_upload_timer, every 10-15 minutes will do that. Check it
every 10-15 minutes, if server_IP is changed then upload.
(and reset force_update_time). The goal, to get information
as accurate as possible with minimum use of bandwidth will
be met.
Example:
Minimum update 10 min.
Forced update 60 min
In this way the server state will be check every 10 minutes
and only uploaded when the server is changed. The
information will be 'refreshed every 1 hour' if no server change
occurred.
000 connect to server - upload - forced_update_counter reset
to 60min.
010 min no server_change
020 min no change
030 min server_change - upload - Forced_update_counter
reset to 60min.
040 min server_change - upload - Forced_update_counter
reset to 60min.
060 min no change
070 min no change
080 min no change
090 min no change
100 min no change, forced update counter reaches 0 -
upload -
Anywhere between 20-29 min. the server changed, and
between 30-39 min. its changed again (maybe even multiple
times) but resulting in only two updates. In this way
information will be accurate to a period of 10 min, but upload
frequency is only 3 times in 100 minutes.
Maybe I would be an idea to log this information in a log file,
so the reliably of servers can be measured?