You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2023. It is now read-only.
One of the limitations of using a DHT as an asynchronous messaging layer is that pointers expire (e.g. after 7 days). Another limitation is that the DHT retriever is a polling mechanism (currently polling every hour), which isn't real-time.
Duo Search wants to provide a caching layer for these asynchronous offline messages to prevent pointers from expiring, and to accelerate delivery of DHT records in case of a flaky connection or a temporary disconnection. For such a caching layer to be built there needs to be a facility to pass offline records to a node. I'll bring up this point later today on the technical call.
The text was updated successfully, but these errors were encountered:
JustinDrake
changed the title
Directly pass DHT record
Directly pass DHT record to node (without polling)
Nov 28, 2016
Pointers expire, but they are republished by the node until it gets a response from the recipient (there is an eventual timeout of like 30 days but that is configurable).
Also, the polling is really only needed when a node comes online. Once they are online the messages can be sent directly. The DHT really shouldn't be used if both nodes are online, except for maybe when one node has severe firewall issues.
What if the node stays offline longer than the expiration period?
the polling is really only needed when a node comes online
I disagree with that. A node can think it is online (e.g. the openbazaar-go daemon is running), but actually it is unreachable (e.g. some sort of network failure). Messages to such a node would be sent to the DHT, polled up to an hour later.
On another note (relevant to Duo Search) it would allow us to implement #98.
As part of the technical hangout on Monday November 28, there was agreement that adding a new MessageType to hook into the retriever's attemptDecrypt function would be a minimal change that allows for nodes to directly communicate offline records. This gives service providers the flexibility to build relays around offline records that can be cached and communicated at will.
One of the limitations of using a DHT as an asynchronous messaging layer is that pointers expire (e.g. after 7 days). Another limitation is that the DHT retriever is a polling mechanism (currently polling every hour), which isn't real-time.
Duo Search wants to provide a caching layer for these asynchronous offline messages to prevent pointers from expiring, and to accelerate delivery of DHT records in case of a flaky connection or a temporary disconnection. For such a caching layer to be built there needs to be a facility to pass offline records to a node. I'll bring up this point later today on the technical call.
The text was updated successfully, but these errors were encountered: