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
creating this issue here first for lack of a better place
Now that we have #44, I think we should start thinking about an additional interface for service discovery. The rational being, in the past rendezvous services (servers), provided a peer discovery mechanism, the proposal in #44 satisfies this requirements and can be adapted to be used as a pure peer discovery mechanism that implements interface-peer-discovery. However, we're lacking an interface to describe the new operations that rendezvous brings about, namely registering and discovering peers under a specific namespace. Defining an interface allows us to implement this functionality using alternative mechanisms, such as DHT.
A rendezvous service can satisfy this two use cases - pure peer discovery defined under interface-peer-discovery and service discovery interface-service-discovery.
I'm still not %100 sold on the naming, so take it with a grain of salt atm. The gist of the operations I want to convey with this interface can be summarized with:
A peer wants to be able to register and be discoverable under a certain namespace
A peer wants to discover other peers registered under a certain namespace
EDIT:
marked discover params as optional (? means optional)
added the word peer to in the past rendezvous services (servers), provided a...
added DiscoveryResponce type to allow returning a timestamp along side the peer
corrected DiscoveryResponce to return a list of peers and a timestamp
The text was updated successfully, but these errors were encountered:
creating this issue here first for lack of a better place
Now that we have #44, I think we should start thinking about an additional interface for service discovery. The rational being, in the past rendezvous services (servers), provided a peer discovery mechanism, the proposal in #44 satisfies this requirements and can be adapted to be used as a pure peer discovery mechanism that implements
interface-peer-discovery
. However, we're lacking an interface to describe the new operations that rendezvous brings about, namely registering and discovering peers under a specific namespace. Defining an interface allows us to implement this functionality using alternative mechanisms, such as DHT.A rendezvous service can satisfy this two use cases - pure peer discovery defined under
interface-peer-discovery
and service discoveryinterface-service-discovery
.Here is a very rough first draft (pseudo flow):
I'm still not %100 sold on the naming, so take it with a grain of salt atm. The gist of the operations I want to convey with this interface can be summarized with:
EDIT:
peer
toin the past rendezvous services (servers), provided a...
DiscoveryResponce
type to allow returning a timestamp along side the peerDiscoveryResponce
to return a list of peers and a timestampThe text was updated successfully, but these errors were encountered: