For GetBlock, as part of the FindBlock, in the current implementation a fog on receiving the request checks its local data structure to see if it contains the block locally and adds itself to the list of candidate fogs. It then looks into the bloom filters of its neighbours and on possibility of containing the block, it makes an api call to the neighbour to check whether the neighbour actually contains it or not. These neighbours are also added to the list. Similar procedure is done for the buddies with one change, the buddy also contacts its own neighbours as well to find the suitable replica fogs. However this leads to a very high number of network calls which can be reduced by using the successful response from bloom filters as an indicator of possible containment of the block.
This can be done using only the contacted fog's local data and the bloom filters of its neighbours. If the bloom filter of a neighbour indicates that the block may be contained by the fog, then it will be returned as a candidate fog to the client. The client then uses this list and tries to read a block from them. In case the block is not found among these fogs, then the block is not present on the fog and its neighbors and thus the buddies should be contacted to get the data. A similar bloom filter handling can be done for the buddies as well. Also a force flag can be passed which when unset will do the efficient version mentioned above while a set flag uses the current implementation to make sure proper replicas are returned as part of FindBlock.
skmonga
commented
5 years ago
For
GetBlock, as part of theFindBlock, in the current implementation a fog on receiving the request checks its local data structure to see if it contains the block locally and adds itself to the list of candidate fogs. It then looks into the bloom filters of its neighbours and on possibility of containing the block, it makes an api call to the neighbour to check whether the neighbour actually contains it or not. These neighbours are also added to the list. Similar procedure is done for the buddies with one change, the buddy also contacts its own neighbours as well to find the suitable replica fogs. However this leads to a very high number of network calls which can be reduced by using the successful response from bloom filters as an indicator of possible containment of the block.This can be done using only the contacted fog's local data and the bloom filters of its neighbours. If the bloom filter of a neighbour indicates that the block may be contained by the fog, then it will be returned as a candidate fog to the client. The client then uses this list and tries to read a block from them. In case the block is not found among these fogs, then the block is not present on the fog and its neighbors and thus the buddies should be contacted to get the data. A similar bloom filter handling can be done for the buddies as well. Also a force flag can be passed which when unset will do the efficient version mentioned above while a set flag uses the current implementation to make sure proper replicas are returned as part of
FindBlock.