This is by far one of the most interesting projects i saw lately and i will keep my eye out for this one for sure!I do have a question: What determines the precedence order when several equal entities wish to hire computational resources at the same instance?
If 2 different people for example both offer to pay the exact same price for the exact same resources, put their offer at the exact same time in the system, which one gets the computational power first? (assuming there is a limitation in the available computational power in total and its not enough for both tasks at the same time). How is it decided in a case of a complete tie in demands?
Hope my question makes sense...
Very good question!
The ultimate theoretical answer is that it's up to the providers and publishers choice. But of course Xennet will be predefined with settings so non-technical users will still be able to rent their computers and get paid, in (probably almost) one click. Yet, the client will be highly customizable. My current plan is to let a JS scripting ability on the client for inputting complex user-defined filters and preferences.
The practical answer for when users do not handle this situation manually and relies on the client's defaults, requires me to highlight several points:
1. As you stated correctly, publishers publish (over the blockchain) a request for providers to connect, including their IP address, and providers connect to them.
2. Some not-very-necessary-for-this-answer background: The publisher do not state a price for a unit of CPU/RAM/etc or time. They state how much they would pay for standard programs, i.e. some common phoronix-test-suite benchmarks. The providers also state their price in terms of canonical benchmarks. Then, the linear-algebra algorithm determines how to decompose those prices into the prices per CPU instruction, RAM fetching etc., and determines the bill at runtime. The algorithm knows how to (optimally!) compensate over the variance between the different kinds of hardware. It's a bit sophisticated and advanced-math mechanism, see our docs for more details. For our case, what needs to be concluded is that not only the publisher's requirements determine a match, but also the performance of each provider, while each having various models of hardware.
3. Each provider will tend to serve several publishers in parallel. If each provider serves 10 publishers, then the risk of both provider and publishers decreases by about x10, since if a publisher do not pay, the provider lost only 10% (note that payments occur every few seconds in a frictionless manner thanks to the Micropayments algorithm, so there will never be a big loss by all means), and if the provider is gone, the publisher loses only the work of 10% of a PC, not 100%. Hence, back to your question, the desired behaviour is to serve both publishers in parallel.
4. Your question still remains if we have many (say 100) publishers with the very same parameters. It is indeed a realistic case: for example, many researchers use Gromacs for molecular dynamics simulation, and they can even work on the same institute with the same terms. So how will Xennet handle this?
5. Same rationale of 3, i.e. reducing risk, points to another risk-decreasing behaviour: say I do have 100 identical publishers. On such case the client will just pick publishers randomly. This is a risk-reducer since it spreads the risks among all nodes.
6. Note that if from that identical publishers, some of them either have richer history than others (seen at the ledger), or, if my specific node served one of them in the past and kept some reputation measurement for this publisher (will be done automatically by the client), it will prefer the one with more reputation.
I hope I addressed your question.
Please (you and everyone) do not hesitate to ask any kind of question about Xennet.
P.S.
"one of the most interesting projects i saw lately" just one? show me another with the same magnitude of redemption
