A Be-Right-Back Function on closing and re-starting eMule
Posted 18 May 2011 - 05:26 PM
I don't know if I really want to ask for this feature/ idea, but like to discuss it anyway.
How about a new / alternative be-right-back behaviour when closing and starting eMule.
"Useful" mostly /only when restarting eMule within short time.
Let's say closing eMule the new BrB-way, eMule would check some conditions (like : is connected, has run for at least x hours, etc.) and then gather and write lots of data into some hyothetical brb.dat file, to maybe - if suitable - re-use them informations on a more or less inmediate restart.
So on closing, eMule would write down :
- date and time
- list of shared files with :
-- number of complete sources▓
-- published or not in Kademlia; and if published : published when / how long ago
-- # of interested clients at this moment▓
- a nodes.dat with all the (good or better) contacts of this moment.
- the routing table(s) or whatsthename - all this bucket stuff
- whatever else I forgot or didn't think of.
- I am not interested in saving sources and such! I trust eMule to find them anyway.
So when I re-start eMule, it would load the brb.dat and compare : if time is roughly the same (max. say 5 minutes ?) and WAN-IP is the same (and identity?),
then restore "old" contacts list, other Kad-stuff, and shared files information.
If not, then start the normal way.
What for ?
- It ends the Kademlia misrepresentation in an inmediately re-started eMule :
In a inmediately re-started eMule, it looks like as if none of my files are known to Kademlia / my eMule is not known as a source; and only 200 orange contacts are shown.
Which to my limited understanding is not the truth - with WAN-IP being the same as before the situation is the same as before.
Anyone looking for files which my eMule has not published again after the restart, will (well, should) still be able to find my eMule just the same.
And all the contacts my eMule had just minutes ago - they have no idea that my eMule was off for a moment - right ?
(well, OK, the few ones that asked right when my eMule was off, but those will only mark my eMule down one step, so mostly not eliminate my eMule from their contact list / buckets / whatever mystery Kad-stuff)
- smarter publishing of files in Kademlia at session (re-)start :
eMule would not waste resources on redundantly re-publishing files it has published just few minutes ago.
Instead it would first publish yet-unpublished or published-long-ago files.
- ▓ : more information available to user after an eMule restart.
Maybe I want to manage files - keep or out of share, adjust priorities, whatever. But not without knowing what file is how un/popular and such.
What you won't know until eMule has run for at least so-many-hours.
- subsequent additional feature requests
like an optional Kademlia kick-start : if eMule gets restarted only the next day or so, and/or with new WAN-IP, then use the brb.dat to find some more popular files in our share, and publish those first.
So we get some clients to upload to asap.
That can sometimes get tricky if you do not download, share mostly very rare files and use no / no properly working ed2k-server.
btw. - are there any mods offering more or less any of this ?
Posted 18 May 2011 - 07:04 PM
Isn't that the only part, that a "normal" user will consider as a nice new feature? Also saving the upload queue might be not bad in such case. The rest of it is for the... "other" users .
Posted 18 May 2011 - 08:01 PM
Posted 19 May 2011 - 07:49 AM
For low ID the situation is a lot worse. First, you have to find a buddy, and sometimes it takes hours.
I do not think that such a feature would mean huge difference for the network, but it is very nice from user's point of view.
Otherwise, I agree with the Wizard: save all and restore all whenever it is appropriate (upgrade might be an exception, btw).
Posted 20 May 2011 - 05:42 AM
IMHO the current eMule version should be stored... thus, a new version could decide which data to use and which data should be discarded because it's outdated
Nevertheless, that would be a nice function to have...