[coluche]

hej,
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.

what :

So on closing, eMule would write down :
- date and time
- WAN-IP
- identity
- 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

example :
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 ?

[Link64]

coluche, on 18 Mai 2011 - 07:26 , said:

- I am not interested in saving sources and such! I trust eMule to find them anyway.

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 .

[tHeWiZaRdOfDoS]

Almost all of that information IS already stored... IMHO the only thing that would enhance eMule would be if the current connections, queue time, etc. would be stored so one could restart eMule (after upgrade, etc.) without eMule searching for sources and starting publishing again - this would lower the overhead and prevent getting banned by asking too often.

[fox88]

coluche, on 18 May 2011 - 09:26 PM, said:

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.

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).

[tHeWiZaRdOfDoS]

fox88, on 19 May 2011 - 09:49 AM, said:

Otherwise, I agree with the Wizard: save all and restore all whenever it is appropriate (upgrade might be an exception, btw).

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...

[P2Pmurphy]

Supported.

This is something I was thinking about for ages ... and didn't get why it hasn't been implemented already!

This post has been edited by P2Pmurphy: 09 July 2011 - 09:57 AM

[DatHebIkWeer]

I heard some mods already have a function to store a source for later. I would love to have a feature like that in eMule.