...does the server check for a response of some sort to confirm that a block was completely searched?
Basically yes - not a single block, but a block interval. See the green text in
"Yesterdays bug"For example if I have block 50-100 and at block 60 I close my client, does the server know that my block was not completed and someone else will need to finish looking through it?
If you simply run the client in "auto" mode (as 99% of clients do), you got the block
s 50-100 from the server, because the client asked the server "give me work for X cpus for Y time". This is a get_work message client -> server and at the same time a promise to finish that work.
Now if you close that client as in your example, your client will not deliver
at the end of the cycle a proof of work that the given interval was searched. Therefore ALL of the blocks in the promised interval are considered not having been done and will be reissued again.
---
If you manually define which blocks your client should compute (
-p <from>-<to> see
"Going no-auto") the server does not even know about your clients work until it finishes its self-imposed work. Only upon finishing, it delivers PoW to the server and the server will add this manual interval to the list of blocks done and also credit the client these blocks done.
This is a part of the server log. The IPs and the client-Ids (except 1ff65d1e0f08af7529e9c9f0a591f263) I have changed. The timestamps and the block ranges are original. For readability I also added client name aliases.
...
1475124925 127.0.0.1 [11673395, 11674010] <<< 60b725f10c9c85c70d97880dfe8191b3 (A)
1475124926 127.0.0.1 [11692283, 11692898] >>> 60b725f10c9c85c70d97880dfe8191b3 (A)
1475125025 127.0.0.2 [11668291, 11671482] <<< 3b5d5c3712955042212316173ccf37be (B)
1475125025 127.0.0.2 [11692899, 11696090] >>> 3b5d5c3712955042212316173ccf37be (B)
1475125073 127.0.0.3 [11662369, 11663844] <<< 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125073 127.0.0.3 [11696091, 11697566] >>> 2cd6ee2c70b0bde53fbe6cac3c8b8bb1 (C)
1475125088 127.0.0.4 [11674011, 11674036] <<< e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125089 127.0.0.4 [11697567, 11697592] >>> e29311f6f1bf1af907f9ef9f44b8328b (D)
1475125118 127.0.0.5 [11697593, 11698960] >>> 1ff65d1e0f08af7529e9c9f0a591f263 (rico)
...
Most of the time, we see a client delivering (<<<) pow of an interval done and immediately getting (>>>) a new interval.
You can see that A gets [11692283, 11692898] after having delivered [11673395, 11674010].
Roughly 100 seconds later, B delivers [11668291, 11671482] and gets [11692899, 11696090]. As you can see it starts off where end of work for A was. Same with C and D. Last entry is my workstation, where I started up LBC at the time, so it fetches a work interval (starts where end-of work for D was) and there is no previous delivery.
As mentioned in the referenced text, sometimes clients do not deliver promised work within a certain time frame, so the work will be reissued.
Then there is also a global overview of blocks done, which looked today morning like that:
[["0",10255010],[10255652,10292471],[10292937,10639099],[10639113,10928680],[10929361,10934248],[10934857,10964934],[10965579,10990212],[10990841,11036530],[11037955,11040222],[11040863,11086284],[11087069,11105776],[11106417,11133744],[11133759,11274716],[11274731,11392940],[11394309,11413182],[11413803,11437418],[11437471,11583428],[11583443,11718436],[11730757,11745286],[11751343,11754328],[3515625000000,3515625030841],...
You can see the pool "forefront" somewhere behind 11754328, this is where new work intervals will be reissued. The [3515625000000,3515625030841] is an interval that is the result of a manual -p where someone ran their client for a day.
You can also see, there are missing intervals in there. First one 10255011-10255651. These are 640 blocks that have been not or not yet delivered back after they have been promised. If the clients who promised them will not deliver back, this range will be reissued by the server.
So yes, the blocks 0 - 10255010 (the first ~ 10753157365760 keys) have been searched completely already. As the holes are getting filled, this first interval grows.
Rico
Thanks, I appreciate you taking the to explain all of that, 1 small suggestion would be to have a live stream of work being done/completed, that would be quite cool. Hopefully I will get an address soon.
1. How long does the server allocate to a client to find a block before reissuing?
2. When was the balances data created?