On Mon, Dec 26, 2022 at 4:42 PM Jens Alfke <j...@mooseyard.com> wrote:
> Thanks. I then spent some time trying to figure out why this scenario > occurs — when the local peer received the capability Carol from the remote > one, shouldn’t it have been marked in the protocol as being a peer exported > by the recipient? > > I think this can happen as follows; is this correct? > > 0. I’ve already sent the capability Carol to the remote peer earlier in > the connection, so the peer has a reference to Carol. > 1. I send an RPC call to acquire a remote capability, and allocate a > (negative) remote capability # to it. Call it X. (I think this is what the > protocol calls a promise?) > 2. Before the response arrives, I pipeline some more RPC calls addressed > to X. > 3. I get a response to the first RPC call, identifying X as my capability > Carol. > > At this point I can remap X to point to Carol, but I’ve already got some > messages in flight addressed to remote capability X. I assume what happens > to these is the peer just sends them back to me, substituting Carol for X, > and then forwards my reply back to me? Thus the problem that I might send > local messages to Carol that would arrive before the echoed messages to X > even though I sent them later. > That's correct, except one minor detail: I'm not sure what you mean about "(negative) remote capability #". There are no negative numbers. The caller assigns a question ID to the outgoing RPC, and can identify expected results for promise pipelining by the question ID plus a field path. > A different architectural solution to this problem might be for a peer to > reject an incoming request addressed to a capability that isn’t local. > Instead it would return an error indicating “X isn’t mine, it’s your Carol, > so forward it there”. > Sure, but this would have several problems: * If the RPC system is expected to deal with it transparently, then that implies the RPC system has to keep a copy of every message it has sent on a promise, until either it gets a response or the promise resolves, wasting memory in order to handle an unusual situation. * If the RPC system is NOT expected to deal with it transparently, then the application has to deal with it. This would compromise the abstraction, as application code would now have to be written with awareness of which objects reside in which vats in order to be ready for this scenario. * In some three-party scenarios (when that is implemented), it would result in extra network round trips. Imagine a scenario where a client talks to a server in a remote datacenter, and the server then redirects the client to an adjacent server. In a naive redirect scenario, the first server must send a message to the client redirecting it, and the client must re-send the message to the second server, all before the second server can receive the message at all. This is an extra round trip on the long-distance connection between the client and the two servers. With Cap'n Proto's approach, the first server directly forwards the request to the second server, while in parallel letting the client know to expect the response from that server. The second server can then send the response directly to the client. So no extra network round trip is needed. > But either way, isn’t there still a race condition if, in a new step 2.5, > I send a message to local Carol? This message was sent after the message to > X but arrives before I discover X is Carol, so it’s received out of order. > E-order only guarantees that calls made on the same capability will be received in order. If you make calls on two different capabilities that, unknown to you, end up pointing to the same destination object, no guarantees are made regarding the order in which those calls are delivered. This has been shown to match what developers intuitively expect in practice. -Kenton -- 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 capnproto+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/capnproto/CAJouXQm1prYCndGsgbuHJm15UXdwK3fBvApfVM5G1%3DKbmhD9YQ%40mail.gmail.com.
