Brilliant! I shall have a go at that tomorrow. Would it be possible for me to use udp instead of tcp, or would that be pushing it too far?
On Wed, 10 Jul 2019, 20:07 Kenton Varda, <[email protected]> wrote: > Hi Harlan, > > In the C++ library, you can get the client's IP address if you decompose a > few classes. First, make sure you're using rpc-twoparty.h directly and not > ez-rpc.h. On the server side, you'll want to copy the class > capnp::TwoPartyServer and modify it a bit. When the code receives a > connection -- whose type is `kj::AsyncIoStream` -- you will want to call > stream->getpeername() to get the client's IP address. You can then > construct a bootstrap capability to use for that specific connection, and > pass the IP address into its constructor. Now your server knows the client > IP! > > (In theory, you're supposed to get a similar result more easily by > implementing the `BootstrapFactory` interface... however, with > TwoPartyVatNetwork, this interface currently doesn't tell you anything > interesting except that the other side is a "client". In theory with a > multi-party VatNetwork implementation, you'd expect the VatId passed to the > factory function to have more meaningful information, but we don't have > that at present.) > > -Kenton > > On Wed, Jul 10, 2019 at 2:14 AM harlan.connor via Cap'n Proto < > [email protected]> wrote: > >> 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 < >>> [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 [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/93ce1980-9f11-4db9-91b2-607d8dc79e71%40googlegroups.com >>>> <https://groups.google.com/d/msgid/capnproto/93ce1980-9f11-4db9-91b2-607d8dc79e71%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/c1e33090-2666-4291-b2e6-9c83ddbb82fd%40googlegroups.com >> <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/CAERRK%3DSoSsjTos60BmCuwQd4u9f0SN2%3D6k7ioF9ni5z%3D8ij1uw%40mail.gmail.com.
