Official eMule-Board: Transfer Credit - Official eMule-Board

Jump to content


Page 1 of 1

Transfer Credit Rate Topic: -----

#1 User is offline   Mig92 

  • Newbie
  • Pip
  • Group: Members
  • Posts: 1
  • Joined: 22-January 19

Posted 22 January 2019 - 08:03 PM

I don't mind sharing, but waiting to complete downloads for days or weeks while I have uploaded 20TB and downloaded “only” 2 is frustrating. I know the “smart” strategy is to unshare everything except the files I am downloading, but I'm not THAT selfish.
The issue I have comes in part because I upload to client A and download from client B. To put my selfishness on the table: I would benefit if I could transfer credit from A to B. I understand concerns for TFT and the anti trading sentiment on this forum. However, I would challenge anyone to explain why uploading to A and downloading from B is trading.
The basic concept of a payment channel in crypocurrencies is that clients who don't know each other can transfer credit through a chain of intermediaries, where everybody only trusts and deals with their neighbors. In crypotcurrencies this trust between neighbours is enforced by what are called smart contracts.
I don't propose building blockchains and lightning networks, allthough I have to admit this was the starting point of my line of reasoning. My current line of thought is developed through process of elimination.
In essence I realized that we have a quantifiable means of knowing to what extent we can trust the clients we know. We already log it in the credit file. The easy algorithm to quantify the amount of trust we have in a client is 2*(ul-dl), but we can get more fancy, if we want. Our equivalent of a payment channel is asking people who “owe” us if our source “owes” them. And inversely, if someone enters our waiting list, we can ask the people we “owe”, if they happen to “owe” that client. By extension they can also pass on the question.
If the answer is yes we can transfer as much credit as we trust through the channel, and be on our merry ways.
Imagine the situation:
A has uploaded to B, who has uploaded to C, who has uploaded to D.
A now enters the waiting list of D. No credit here. However D is willing to upload to C,who is willing to upload to B,who is willing to upload to A. I think we can all agree routing the actual parts from D to C to B to A is not the most efficient use of bandwith, so I propose D upload to A and all clients update their credit files as if they had routed the amount of parts. In essence that is all.

We need some sensible precautions with respect to confirmation of the transaction. Everything else is efficiency of programming. We can borrow handsomely from path finding and tree searching wisdom to design an efficient implementation. We can supply credit partwise, or differentiate between max allowed credit and actual use of credits.
0

#2 User is offline   pier4r 

  • Ex falso quodlibet ; Kad is the major concept behind emule.
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 588
  • Joined: 31-March 09

Posted 28 August 2019 - 10:58 AM

View PostMig92, on 22 January 2019 - 10:03 PM, said:

I don't mind sharing, but waiting to complete downloads for days or weeks while I have uploaded 20TB and downloaded "only" 2 is frustrating. I know the "smart" strategy is to unshare everything except the files I am downloading, but I'm not THAT selfish.


Well, the request was done multiple times over time. Really a lot of times and I can understand what you mean.

Emule is a bit like "give, and one day will get back". It is not TFT (although in 2011/2012 I implemented a variation of emule ZZUL TRA with a bit of that).

The "share the credit" problem is not so simple to solve. Indeed one huge contribution from bitcoin is exactly the blockchain. That solves the problem but it is really heavy on the client. Even keeping only IDs of users active in the last month, and pruning anything else, it would be quite space intensive. Add to this that the dev scene for emule shrank a lot in the last years, and you get a little.

Not even bittorrent has credit, rather it focus on the current files. You can achieve the same either, as you said, sharing only what you want to get (but then the file availability dies), or keeping every other file at ultra low priority and those that you are sharing at the highest priority. In that way you achieve a similar result without removing your files from the network (that is a bit better).

Or, since you have uploaded 20 TB, you don't mind to wait. For me p2p is "if I need a file immediately, I buy it otherwise I wait". Sometimes I wait a year before getting something, but it is really rewarding.

Especially for niche interests, it is a patience game. Consider that with torrent you don't have such content to begin with, exactly because torrent is laser focused on few files at once, thus the nice file disappear unless there is a community behind them.
>>>Feature Request (ICS) or SOTN, EmuleCollectionV2 >>> Emule on old hardware (intel pentium 2 or 3 - via c3 - and so on) with good OS settings and enough ram (256+ mb): great >>>user of: eMule - Xtreme - ZZUL bastard - SharX - SharkX 1.8b5 pierQR - ZZUL-Tra - ZZUL-Tra-TL - kMule - Beba

Extended signature: click.
0

#3 User is offline   PhilGenesis 

  • Member
  • PipPip
  • Group: Members
  • Posts: 22
  • Joined: 02-November 19

Posted 06 November 2019 - 11:10 AM

@pier4r "Consider that with torrent you don't have such content to begin with" : you have MUCH more content on torrents, even with niche files. You just have to be on the good private tracker.
I love emule but with less than 200 000 users you can't have the same library that other networks used by millions.
0

#4 User is offline   Campo 

  • Advanced Member
  • PipPipPip
  • Group: Members
  • Posts: 64
  • Joined: 18-June 19

Posted 06 November 2019 - 05:06 PM

i have to use emule for it. Iam searching of course for torrents on the special tracker first (after i couldnt get the file or torrent over the fansub group). but if it is older than 2 years, chance drop extremely. i dont think i need to tell you, what the chances are with over 10 year old files or 20 years. sometimes its just 1 group that had released a subtitle. even the raw file in japanese isnt always avaible with 1 source.

Since a lot people didnt use emule anymore, these files are nearly lost. The private tracker are trying to get the hands on such projects, but arent successfull.

Best example is my internet situation, my ISP give me just a tunneled IP for ipv4. so no high id possible (and didnt used emule at all).after years i had found a vpn service, which could gave me a high id. as soon as i was online with high id, the uploads startet. the queue got over 1000 within 4 hours. the connection speed was 256kilobytes/sec. then the vpn service didnt work anymore... i tried something else without success. then, this yeaer i found airvpn and i managed to configure the ports = high id again. even now after 15 minutes, i get some uplaods already. my speed is now limited at 2100kilobytes/sec and still there are people who get the files from me. of course i know now a lot of the nicknames with their upload/download from/to me. i have gathered a lot of credits, which will never have files, i want. but i there appears a source, the chances that iam first, is exremly high (its good for all, because the other will get it some minutes later from me.

as i said, some people are appearing a lot in the list. even with new stuff, which i got over torrent. so these guys are just using emule. but there are also guys, who are uplaod to me if i find some old stuff and start to test the download. i then think "maybe that or this guy may have it".

so tahts my short story, why i cant stop using the ed2k/kad network. theres no other chance, in a lot of cases, to get that file.

PS: i use morph at the moment with the best possible detection for bad behavior. anybody who have a normal confogiration can get as much as they want, but the "banned" number gets to 10 very fast after programm start. i think they only geht some megabytes until the ban strikes^^ iam for fair use. there are also people who seem to have very slow connections. theres a guy with over 20gbytes from me with only 5-6kilobytes :D he even helped me on some files, slow with 3kilobytes, but hey^^ i got it complete :D
0

#5 User is offline   Andu 

  • Morph Team
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 13015
  • Joined: 04-December 02

Posted 09 November 2020 - 01:20 AM

In the past this was also a technological challenge. I wonder if blockchains could resolve the technical issues we faced in the past. After all a distributed ledger is exactly what you want for this kind of system.
Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.


Dark Lord of the Forum


Morph your Mule

Need a little help with your MorphXT? Click here

0

#6 User is offline   emule_user_downunder 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 161
  • Joined: 20-March 04

Posted 16 November 2020 - 04:21 PM

You want a distributed PERMANENT, NON-DELETEABLE record of your anonymous file-sharing?
Not me thanks!

0

#7 User is offline   Stulle 

  • [Enter Mod] Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5804
  • Joined: 07-April 04

Posted 16 November 2020 - 04:53 PM

View Postemule_user_downunder, on 16 November 2020 - 04:21 PM, said:

You want a distributed PERMANENT, NON-DELETEABLE record of your anonymous file-sharing?
Not me thanks!

N'ah, it would be quite sufficient to have the sender and the recipient to agree on what amount of good data was transferred and put that in a block chain. Possibly one would actually need a couple of third parties to decide if the information matches and they all share the same information. From that trusted information it would be possible for anyone in the network with access to the blockchain to calculate how positive a client is behaving and push his advance in the queue accordingly.

I see two major downsides:
  • To the best of my knowledge blockchains grow indefinitely which will put a burden on every network client in the long term, especially because we need to be precise to the byte.
  • The network, to me, appears fast and small to the point that the benefit to be gained is negligible. Hence, I don't think it's worth all the hassle.


Am I missing something?

PS: Also, I am not a fan of blockchains because their hyping for any ridiculous application (such as storing manufacturing equipment sensor data) pretty much just burnt the entire concept crisp for me.
I am an emule-web.de member and fan!

[Imagine there was a sarcasm meter right here!]

No, there will not be a new version of my mods. No, I do not want your PM. No, I am certain, use the board and quit sending PMs. No, I am not kidding, there will not be a new version of my mods just because of YOU asking for it!
0

#8 User is offline   emule_user_downunder 

  • Splendid Member
  • PipPipPipPip
  • Group: Members
  • Posts: 161
  • Joined: 20-March 04

Posted 16 November 2020 - 10:49 PM

Data has a right to die.
Blockchain is forever.
I agree with both your points.
The days of fighting for priority and bandwidth are probably not so much of an issue any more. Patience seems to be the issue.
Isn't blocking nodes sending bad data already happening?

0

#9 User is offline   Stulle 

  • [Enter Mod] Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5804
  • Joined: 07-April 04

Posted 17 November 2020 - 07:01 AM

View Postemule_user_downunder, on 16 November 2020 - 10:49 PM, said:

Isn't blocking nodes sending bad data already happening?

I guess it is but the point was that data might become corrupted and thus unusable to the recipient. No point in acknowledging bad data as "credits".
I am an emule-web.de member and fan!

[Imagine there was a sarcasm meter right here!]

No, there will not be a new version of my mods. No, I do not want your PM. No, I am certain, use the board and quit sending PMs. No, I am not kidding, there will not be a new version of my mods just because of YOU asking for it!
0

#10 User is offline   Andu 

  • Morph Team
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 13015
  • Joined: 04-December 02

Posted 21 November 2020 - 04:54 PM

I'm not saying this is necessarily the smartest solution or that there aren't ways to actually improve on the basic idea. Just saying there is a tech out there now for a distributed ledger and that is all that blockchain really is. If you ignore all the hype and the buzzwords and break it down to the core of the tech that's what it does. Maybe one could add expiry dates to the credit you store in the blockchain.

If talking about these kinds of technological solutions I think it's important to forget what retarded stuff other people are doing with the tech and focus on what it is actually good for then decide from there if it fits the application.

Even though the network is smaller I have even now seen people asking for ways to cap upload to 10kb/s while having unlimited dl. A system that encourages opening up the ul pipe won't hurt.

If you are downloading copyrighted stuff it will not help you that you only uploaded at 10kb/s anyway. Just get a VPN and learn live with the LowID.

Maybe you are right though Stulle. It might be smarter to focus efforts on finding a more efficient way of using LowID clients behind VPNs rather an encouraging uploads. Ever since the beginning of eMule the LowID clients were often those with the largest upload pipes. Unlocking their full potential might give the network access to much more bandwidth than getting the 10kb/s clients to raise their upload a bit.

This post has been edited by Andu: 21 November 2020 - 04:55 PM

Three Rings for the Elven-kings under the sky,
Seven for the Dwarf-lords in their halls of stone,
Nine for Mortal Men doomed to die,
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
One Ring to rule them all, One Ring to find them,
One Ring to bring them all and in the darkness bind them
In the Land of Mordor where the Shadows lie.


Dark Lord of the Forum


Morph your Mule

Need a little help with your MorphXT? Click here

1

#11 User is offline   Stulle 

  • [Enter Mod] Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5804
  • Joined: 07-April 04

Posted 22 November 2020 - 07:07 PM

Fair and true. Let's see where it's going to take us. :-)
I am an emule-web.de member and fan!

[Imagine there was a sarcasm meter right here!]

No, there will not be a new version of my mods. No, I do not want your PM. No, I am certain, use the board and quit sending PMs. No, I am not kidding, there will not be a new version of my mods just because of YOU asking for it!
0

#12 User is offline   DavidXanatos 

  • Neo Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 1469
  • Joined: 23-April 04

Posted 08 December 2020 - 03:33 PM

What you are describing www.tribler.org does for BitTorrent already.
NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
0

#13 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 09 December 2020 - 04:25 AM

View PostMig92, on 22 January 2019 - 03:03 PM, said:

I don't mind sharing, but waiting to complete downloads for days or weeks while I have uploaded 20TB and downloaded “only” 2 is frustrating. I know the “smart” strategy is to unshare everything except the files I am downloading, but I'm not THAT selfish.


Umm, that "smart" strategy doesn't generally work well. ex: when you only share what you are DL you're only UL what you are DL. i.e. you're UL to sources you need, and complete their DL, and once their DL is complete they can unshare it, which leaves you with fewer sources.

Personally, I think blockchains are overcomplicating the issue. The problem is trust and that eMule Clients blindly trust that all Clients are UL. The system needs to change so it doesn't auto-trust all Clients. If the Clients were coded to UL what they are DL that would prove to the network that they are trustworthy. The issue is people can't wrap their brains around the concept that it doesnt have to be TFT with you directly, but to the network in general. On lots of rare files, it's easy to tell which Clients are hoarding chunks and arent playing nice nice. If the Clients were coded to play nice nice then other Clients would know for sure which Clients are cheating the system. i.e. if Clients were coded to share rare chunks then other Clients would know when they see a Client that isn't sharing rare chunks that the code that says "do not modify this part of the code" has been hacked.

View Postpier4r, on 28 August 2019 - 05:58 AM, said:

Sometimes I wait a year before getting something, but it is really rewarding.


Yes, DL rare files can be frustrating. :flowers:

the majority of the hardcore eMule Dev followers who are highly opposed to change said:

Rare files are rare because nobody wants them.


I always hated that idiotic logical fallacy. :respect:

This post has been edited by Sir_Boagalott: 09 December 2020 - 04:28 AM

0

#14 User is offline   Stulle 

  • [Enter Mod] Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5804
  • Joined: 07-April 04

Posted 09 December 2020 - 08:08 AM

View PostSir_Boagalott, on 09 December 2020 - 04:25 AM, said:

Personally, I think blockchains are overcomplicating the issue. The problem is trust and that eMule Clients blindly trust that all Clients are UL.

You are spot on about the trust aspect and I tend to agree about blockchains being overly complicated. However, with an open source client it's even more difficult to create trust because there is nothing to stop somebody from tinkering with the code and thus with the expectable behaviour.

First distrusting and then building trust on a network level is also not very easy to accomplish. It creates a lot of overhead one way or another and there remains the question about persistence of the trust. No point in only checking any number of other clients how much client A is uploading just now. We have to have some kind of record because client A might have uploaded loads but has no recipient to send to right now. But asking other clients for what they know client A sent in the past can be spoofed unless one uses something like a blockchain and can also be lost unless sufficient redundancy of the information is achieved in the network.

Summarizing, the idea of a blockchain is probably one of the better ones if network wide trust and reliable information on upload/download stats is sought. However, I still don't think it is a high priority in this time and age.
I am an emule-web.de member and fan!

[Imagine there was a sarcasm meter right here!]

No, there will not be a new version of my mods. No, I do not want your PM. No, I am certain, use the board and quit sending PMs. No, I am not kidding, there will not be a new version of my mods just because of YOU asking for it!
0

#15 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 09 December 2020 - 12:10 PM

View PostStulle, on 09 December 2020 - 03:08 AM, said:

You are spot on about the trust aspect and I tend to agree about blockchains being overly complicated. However, with an open source client it's even more difficult to create trust because there is nothing to stop somebody from tinkering with the code and thus with the expectable behaviour.

First distrusting and then building trust on a network level is also not very easy to accomplish. It creates a lot of overhead one way or another and there remains the question about persistence of the trust. No point in only checking any number of other clients how much client A is uploading just now. We have to have some kind of record because client A might have uploaded loads but has no recipient to send to right now. But asking other clients for what they know client A sent in the past can be spoofed unless one uses something like a blockchain and can also be lost unless sufficient redundancy of the information is achieved in the network.

Summarizing, the idea of a blockchain is probably one of the better ones if network wide trust and reliable information on upload/download stats is sought. However, I still don't think it is a high priority in this time and age.


The level of trust that you're referring to is overkill for a P2P network. No DL app requires absolute trust like blockchain has. It's not like chunks are $.

Nobody Ever said:

That damn client ripped me off for 2MB, I'm never using this p2p ever again.


It isn't necessarily about distrusting all Clients until proven otherwise. It's more about incentive; with there being positive and negative incentive. Positive incentive is reason to UL to a Client that has proven itself to the other Clients that are DL a given file. Network-wide trust isn't needed. Negative incentive is reasons to not UL to certain Clients that have proven they are breaking the rules, meaning hacked parts of the code that aren't allowed to be modified. A good example is the faqUfullQer's. eMule blindly trusts that all Clients are giving other Clients Queues. That's easily fixed by Q4Q - and that only needs to be soft coded and applicable to rare files. ex: if a file has hundreds of sources q4q doesn't really matter; it's the files that are rare that make q4q vital.

Exactly like you say, with open source anybody can tinker with the code. However, the point is that if certain behaviors were coded into the Clients other Clients would be able to determine when certain Clients are cheating and hacked that part of the code. The way is eMule is coded it takes all Cleints word for it that they are behaving. One of the main issues is without certain behaviours coded into the program there is no way to for our Clients to determine when Clients are cheating the system.

A big part of eMules problem is the fundamental error in philosophy. Most people tend to believe that eMule is a DL program, but the majority of users share way more files than they DL. A big issue is that eMule was coded to be a Client Server when the Client should really be thought of as a File Server. Technically, it should even be viewed as a Chunk Server. i.e. what are the rarest chunks for any given file, and UL the rarest chunks 1st, and have the auto-UL priorities for each file based on Demand. ex: UL the rarest and most needed chunks 1st; vs current method of files availability is irrelevant and UL to all Clients equally based only on time waited.
0

#16 User is offline   Stulle 

  • [Enter Mod] Dev
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 5804
  • Joined: 07-April 04

Posted 09 December 2020 - 02:29 PM

Doesn't make any sense to me. eMule never aimed to be tit-for-tat, which is what you suggest. I for one have way more upload than download. I would already break the system because I am serving others which can in turn not be served by a third party.

Also, I believe there is a fairly high probability for many clients to not have mutual interest in their shared files. Best case scenario would be a kind of a round robin, where A desires something from B and B from C and C from A. But in any such scenario you are either stuck assuming things that cannot be confirmed without a third party or it would fail right in the beginning.
I am an emule-web.de member and fan!

[Imagine there was a sarcasm meter right here!]

No, there will not be a new version of my mods. No, I do not want your PM. No, I am certain, use the board and quit sending PMs. No, I am not kidding, there will not be a new version of my mods just because of YOU asking for it!
0

#17 User is offline   Sir_Boagalott 

  • Golden eMule
  • PipPipPipPipPipPipPip
  • Group: Members
  • Posts: 470
  • Joined: 23-September 02

Posted 09 December 2020 - 03:45 PM

No clue where you get TFT from because that has absolutely nothing to do with my concept at all.

The irony of people making a blockchain suggestion so there could be a round robin, where A desires something from B and B from C and C from A - which sounds pretty damn TFT to me. :-k

You seem to be stuck in the idea that the Clients are Client Servers so for a Client to serve another Client they would require a mutually shared interest in files in order for them to serve each other.

What you are saying has no relevance to what I am saying at all. :flowers:

The Client should use q/file and UL prios based on file availability & chunk availability + demand (# of clients needing it). ex: if theres a 1000 clients in your q for the same file, check the part files of them all and calc the availability of the DL clients, if it's 0 then UL that entire file but only until there is another file with less availability + greater demand, then it UL that file until there is another file with rare chunks with a greater demand; repeat. If the Clients that DL a chunk are coded to UL those rare chunks to meet the demand there is positive incentive to spread the chunk. If a Client hoards rare chunks the other clients will know they are breaking the rules and will have negative incentive to UL to them 1st.
0

  • Member Options

Page 1 of 1

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users