With a hypothetical level-3 capnproto implementation, I don't think you
actually need this feature; you could do something like this:

    interface Node {
        ping @0 ();
        store @1 (key :Data, val :Data);
        findNode @2 (id :NodeId) -> (results :List(Result));
        findValue @3 ...;
    }

    struct Result {
        id @0 :NodeId;
        node @1 :Node;
    }


When doing a findNode, the receiver just hands back a direct reference
to the nodes, so you don't need to know where they are at all; routing
messages would be handled by capnproto itself.

Note that with this arrangement, it's technically possible for more than
one "Node" to live on a single actual machine. This is probably not
terribly useful in this case (except maybe for testing), but shouldn't
break anything.

Of course, none of the current implementations support level 3, so 3PH
isn't actually available.

Quoting harlan.connor via Cap'n Proto (2019-07-10 05:14:49)
>    Sorry, for not making myself clear!
>    For a peer-to-peer system to work, there needs to be some way for nodes
>    to be introduced to each other. This is generally done by sending over
>    an IP address, but (in my understanding) the 3PH system would also
>    facilitate this introduction.
>    3PH rather appealed to me, as it would mean that the initial connection
>    between nodes would be a lot simpler, as I would not have to verify the
>    addresses manually (and end up getting it wrong), nor would I have to
>    iterate through a list, connecting to each one.
>    gRPC has "grpc::ClientContext::peer", which returns the URI of the
>    remote. I was wondering if capnp had something similar.
>    Thanks for your help!
>    On Tuesday, 9 July 2019 21:42:38 UTC+1, Kenton Varda wrote:
>
>    Hi Harlan,
>    Sorry, but I don't understand your original question. I don't see how
>    obtaining the client's address is related to three-party handoff. I'm
>    not sure I understand exactly what the issue is here; maybe you could
>    provide more details?
>    gRPC doesn't have any concept of three-party handoff -- this is a
>    (planned) feature that only makes sense in object-capability protocols
>    like Cap'n Proto. So if your problem is that 3PH is not yet implemented
>    in Cap'n Proto, I don't understand how using gRPC would solve that.
>    -Kenton
>
>    On Tue, Jul 9, 2019 at 2:59 AM harlan.connor via Cap'n Proto
>    <[1][email protected]> wrote:
>
>    Ah well, I guess I'll have to use gRPC. I much prefer the schema of
>    capnp, but I would like to get this to work.
>    On Monday, 1 July 2019 22:45:56 UTC+1, Harlan Connor wrote:
>
>    I've been trying to implement a Kademlia DHT with capnproto, but I
>    cannot work out how to get hold of a client's address.
>    Whilst scrolling through the various discussions, I have seen that the
>    three-party capabilities interface is recommended for similar uses.
>    However, it appears that the current implementation either does not
>    exist, or would route it throught all the nodes, which since this
>    network should scale to many nodes, would be impractical.
>    I have been using the Ez RPC interface, if that makes any difference.
>    Does anyone have any ideas?
>
>      --
>      You received this message because you are subscribed to the Google
>      Groups "Cap'n Proto" group.
>      To unsubscribe from this group and stop receiving emails from it,
>      send an email to [2][email protected].
>      Visit this group at [3]https://groups.google.com/group/capnproto.
>      To view this discussion on the web visit
>      [4]https://groups.google.com/d/msgid/capnproto/93ce1980-9f11-
>      4db9-91b2-607d8dc79e71%40googlegroups.com.
>
>    --
>    You received this message because you are subscribed to the Google
>    Groups "Cap'n Proto" group.
>    To unsubscribe from this group and stop receiving emails from it, send
>    an email to [5][email protected].
>    Visit this group at [6]https://groups.google.com/group/capnproto.
>    To view this discussion on the web visit
>    [7]https://groups.google.com/d/msgid/capnproto/c1e33090-2666-4291-b2e6-
>    9c83ddbb82fd%40googlegroups.com.
>
> Verweise
>
>    1. javascript:/
>    2. javascript:/
>    3. https://groups.google.com/group/capnproto
>    4. 
> https://groups.google.com/d/msgid/capnproto/93ce1980-9f11-4db9-91b2-607d8dc79e71%40googlegroups.com?utm_medium=email&utm_source=footer
>    5. mailto:[email protected]
>    6. https://groups.google.com/group/capnproto
>    7. 
> https://groups.google.com/d/msgid/capnproto/c1e33090-2666-4291-b2e6-9c83ddbb82fd%40googlegroups.com?utm_medium=email&utm_source=footer

-- 
You received this message because you are subscribed to the Google Groups 
"Cap'n Proto" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/group/capnproto.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/capnproto/156277854228.1065.12881308660835681432%40localhost.localdomain.

Reply via email to