1. 16 Jun, 2019 1 commit
    • Kenton Varda's avatar
      Add cheaper way to check size of RPC messages for flow control. · 76e35a7c
      Kenton Varda authored
      Way back in 538a767e I added `RpcSystem::setFlowLimit()`, a blunt mechanism by which an RPC node can arrange to stop reading new messages from the connection when too many incoming calls are in-flight. This was needed to deal with buggy Sandstorm apps that would stream multi-gigabyte files by doing a zillion writes without waiting, which would then all be queued in the HTTP gateway, causing it to run out of memory.
      
      In implementing that, I inadertently caused the RPC system to do a tree walk on every call message it received, in order to sum up the message size. This is silly, becaues it's much cheaper to sum up the segment sizes. In fact, in the case of a malicious peer, the tree walk is potentially insufficient, because it doesn't count holes in the segments. The tree walk also means that any invalid pointers in the message cause an exception to be thrown even if that pointer is never accessed by the app, which isn't the usual behavior.
      
      I seem to recall this issue coming up in discussion once in the past, but I couldn't find the thread.
      
      For the new streaming feature, we'll be paying attention to the size of outgoing messages. Again, here, it would be nice to compute this size by summing segments without doing a tree walk.
      
      So, this commit adds `sizeInWords()` methods that do this.
      76e35a7c
  2. 08 Feb, 2018 1 commit
  3. 19 Sep, 2017 1 commit
  4. 24 Jan, 2017 1 commit
    • Harris Hancock's avatar
      MSVC non-const copy capture workaround · f87b3068
      Harris Hancock authored
      MSVC refuses the following code:
      
      struct Foo { Foo(Foo&) {} };
      Foo foo;
      [foo] {}();
      
      because it only seems to want to consider const copy constructors when
      capturing objects by value in lambda capture lists.
      f87b3068
  5. 07 Oct, 2016 1 commit
    • Kenton Varda's avatar
      Fix RealmGateway to avoid double-transforms on loopback. · 86276457
      Kenton Varda authored
      Previously, in the presence of promise capabilities, a save() request could cross over the same gateway twice (or more!). Some gateways (e.g. Sandstorm's) implement one-way transformations, so this could cause the request to fail when it shouldn't.
      86276457
  6. 23 Jul, 2015 1 commit
    • Kenton Varda's avatar
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an… · d4cd01e9
      Kenton Varda authored
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."
      
      The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection.
      
      The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability.
      
      Thanks to David Renshaw for narrowing this down.
      d4cd01e9
  7. 03 Jul, 2015 1 commit
    • Kenton Varda's avatar
      Refactor how messages are imbued with a capability table. · 5413038b
      Kenton Varda authored
      **The problem**
      
      The methods MessageReader::initCapTable() and MessageBuilder::getCapTable() always felt rather hacky. initCapTable() in particular feels like something that should be handled by the constructor. However, in practice, the cap table is often initialized based on a table encoded within the message itself. That is, an RPC message contains a "payload" which includes both the application-level message structure and a table of capabilities. The cap table has to be processed first, then initCapTable() is called on the overall message, before the application structure can safely be read.
      
      The really weird part about this is that even though the cap table only applies to one branch of the message (the payload), it is set on the *whole* MessageReader. This implies, for example, that it would be impossible to have a message that contains multiple payloads. We haven't had any need for such a thing, but an implemnetation that has such artificial limitations feels very wrong.
      
      MessageBuilder has similar issues going in the opposite direction.
      
      All of this ugliness potentially gets worse when we introduce "membranes". We want a way to intercept capabilities as they are being read from or written to an RPC payload. Currently, the only plausible way to do that is, again, to apply a transformation to all capabilities in the message. In practice it seems like this would work out OK, but it again feels wrong -- we really want to take a single Reader or Builder and "wrap" it so that transformations are applied on capabilities read/written through it.
      
      **The solution**
      
      This change fixes the problem by adding a new pointer to each struct/list Reader/Builder that tracks the current cap table. So, now a Reader or Builder for a particular sub-object can be "imbued" with a cap table without affecting any other existing Readers/Builders pointing into the same message. The cap table is inherited by child Readers/Builders obtained through the original one.
      
      This approach matches up nicely with membranes, which should make their implementation nice and clean.
      
      This change unfortunately means that Readers and Builders are now bigger, possibly with some performance impact.
      5413038b
  8. 06 May, 2015 1 commit
  9. 30 Dec, 2014 1 commit
  10. 12 Dec, 2014 1 commit
  11. 10 Dec, 2014 1 commit
  12. 29 Nov, 2014 1 commit
    • Kenton Varda's avatar
      Simplify exceptions. Eliminate Durability. Rename Nature to Type and simplify it. · 4ee25e43
      Kenton Varda authored
      Distinguishing between "local bugs" and "preconditions" was proving difficult in practice, because a precondition failure in one function may very well indicate a bug in a calling function, but the exception may be thrown through that function, thus when caught the classification is nonsensical. The distinction also was not as useful as imagined. So, I eliminated this distinction.
      4ee25e43
  13. 13 Nov, 2014 1 commit
  14. 04 Nov, 2014 1 commit
  15. 25 Oct, 2014 1 commit
  16. 11 Sep, 2014 2 commits
    • Kenton Varda's avatar
      Fix bug where returned caps would leak if the request was canceled. · 6915e4ff
      Kenton Varda authored
      This only happened if the Finish message indicating cancellation and the Return message happened to cross paths. If the Finish arrived before the Return was sent, then the server would send an empty response. If the Return was received before the Finish was sent, the client would properly record caps in the response. But if they crossed paths, the server would send back a full response with caps, but the client would never bother to inspect that response, thus leaking the caps. Fix is to set the flag to release all returned caps in the Finish message when cancelling.
      6915e4ff
    • Kenton Varda's avatar
      Fix obscure bug where the last outgoing message (and any capabilities therein)… · 26914900
      Kenton Varda authored
      Fix obscure bug where the last outgoing message (and any capabilities therein) would not get released (until a new message was sent, replacing it as the last).
      
      This took hours to track down, because it initially looked like "Release" messages weren't being honored in some cases (when they happened to be releasing a capability from the last message, and no subsequent messages were sent). Initial attempts to capture this in a unit test failed because the test of course used a subsequent call to detect if the capability had been released, which succeeded.
      26914900
  17. 19 Aug, 2014 1 commit
    • Kenton Varda's avatar
      Fix two subtle bugs with embargos, and improve docs. · 1cdcc24b
      Kenton Varda authored
      Bug 1
      -----
      
      If a Resolve message indicated that the promise had been rejected, the code would see the error cap as a local cap and erroneously believe that the promise had resolved back to a local capability, thereby requiring a Disembargo to be sent. The peer, on receiving the nonsensical Disembargo, would throw an exception and close the connection.
      
      The error message seen was: "expected target->getBrand() == this; 'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender."
      
      Bug 2
      -----
      
      Disembargos are sent not only in response to Resolves, but also Returns, since capabilities in a returned message were previously accessible as PromisedAnswers. This means that we must apply the same rule that states that once a promise has been resolved, the promise must from then on forward all messages it receives strictly to the object to which it resolved, even if that object is itself a promise which later resolves to somewhere else. The code which sends Resolve messages was doing this correctly, but the code sending Return messages was not. They now both operate correctly. I've also added more explanation to the documentation in rpc.capnp.
      
      The error message seen was: "expected redirect == nullptr; 'Disembargo' of type 'senderLoopback' sent to an object that does not appear to have been the object of a previous 'Resolve' message."
      1cdcc24b
  18. 20 Jun, 2014 1 commit
    • Kenton Varda's avatar
      Change license to MIT. · 889204fe
      Kenton Varda authored
      For portions currently copyright by Kenton (most of it), transfer copyright to Sandstorm Development Group, Inc. (Kenton's company).
      
      The license change is practically meaningless, as MIT and BSD 2-clause are legally equivalent. However, the BSD 2-clause license is sometimes confused for its ugly siblings, BSD 3-clause and BSD 4-clause. The MIT license is more immediately recognizeable for what it is.
      
      Rémy Blank and Jason Choy (the two non-trivial contributors) are on record as approving this change:
      
      https://groups.google.com/d/msg/capnproto/xXDd2HUOCcc/gbe_COIuXKYJ
      889204fe
  19. 11 Dec, 2013 1 commit
    • Kenton Varda's avatar
      Eliminate the concept of imbuing messages in favor of the simpler concept of… · 3c7efbb4
      Kenton Varda authored
      Eliminate the concept of imbuing messages in favor of the simpler concept of setting a cap table directly on MessageReader / getting one from MessageBuilder.  This eliminates capability-context entirely.  This was made possible by the earlier change which moved capabilities to a separate table rather than storing CapDescriptors inline, but I didn't realize it at the time.
      3c7efbb4
  20. 10 Dec, 2013 1 commit
  21. 06 Dec, 2013 2 commits
  22. 05 Dec, 2013 3 commits
  23. 04 Dec, 2013 1 commit
  24. 29 Nov, 2013 1 commit
  25. 28 Nov, 2013 2 commits
  26. 26 Nov, 2013 4 commits
  27. 25 Nov, 2013 3 commits
  28. 23 Nov, 2013 1 commit
  29. 20 Nov, 2013 1 commit
  30. 18 Nov, 2013 1 commit