Closed navillasa closed 6 years ago
The idea is nice but there is a problem. Let me write down a few examples.
This could potentially leave out contacts without a way to get back into either of the pools. This call ALLOC
can be the first contact with the farmer, aside from joining the routing tables (which not every contact is part of with the renters).
Yes that is exactly the problem I see. The extreme example would be:
I setup a new farmer and register myself on the bridge. My farmer is not stable and is going offline after 10 Minutes. I need more than one day to fix the problem. I will never receive any ALLOC messages. Restarting the farmer will not update lastSeen. Only a few messages will update lastSeen but the chance for a retrieve request is low even for bigger farmer. For a new farmer the chance is 0%. No chance to update lastSeen.
How about a change on the farmer side. At the moment the farmer is patching the bridge contact list only if spaceAvailable, IP, Port or Version are changed. The farmer could validate lastSeen as well. On the bridge side the PATCH request could update lastSeen. That would allow the farmer to restart his node after 24 hours and receive ALLOCs again.
Some more details for this idea:
On the bridge side we would need to update lastSeen here: https://github.com/Storj/bridge/blob/2bfca65571cd89c9dd10e180fa1373f748990cd0/lib/server/routes/contacts.js#L121
On the farmer side lastSeen needs to be validated here: https://github.com/Storj/core/blob/9bdba6fb087892c4972e94699426bb09d9bbe713/lib/network/farmer.js#L382
lastSeen
changes too many times to validate against. However sending a PATCH request to a contact could update the lastSeen property to the latest time, when updating other details. That would avoid any issues with using lastSeen
property as a way to trigger setting spaceAvailable: false
after many failed ALLOC messages.
… when selecting farmers for ALLOC message-sending.
This is based off https://github.com/Storj/service-storage-models/pull/147
Closes https://github.com/Storj/bridge/issues/557