The StreamJsonRpc library offers JSON-RPC 2.0 over any .NET Stream, WebSocket, or Pipe. With bonus support for request cancellation, client proxy generation, and more.
Other
747
stars
149
forks
source link
We should document and test the case of sending the same RpcMarshalable object across several top-level RPC methods #1012
Eric Maupin suggested that he might be passing the same RpcMarshalable object across the same RPC connection multiple times. That is, the creator of the real object sends it as a method argument to several methods.
This pattern concerns me, because if the methods run concurrently I think JsonRpc will see the same object reference and store it only once in our marshalable object handle table, and reuse the same handle each time the object appears. On the receiving side, it will see the same handle each time and use the same proxy. Given the docs require the receiver to dispose of a marshalable object, each of these several methods will presumably dispose the object when they are done. But the first method to do this may end up removing the handle from the marshalable tables kept by both sides, zombifying the other proxies.
If so, this behavior is by design. But we should verify that our docs make abundantly clear that when an RpcMarshalable object is sent over RPC, the sender should truly consider that they don't own the object any more and should certainly not send it again.
Let's review the docs and possibly write a test for this scenario.
Eric Maupin suggested that he might be passing the same RpcMarshalable object across the same RPC connection multiple times. That is, the creator of the real object sends it as a method argument to several methods.
This pattern concerns me, because if the methods run concurrently I think JsonRpc will see the same object reference and store it only once in our marshalable object handle table, and reuse the same handle each time the object appears. On the receiving side, it will see the same handle each time and use the same proxy. Given the docs require the receiver to dispose of a marshalable object, each of these several methods will presumably dispose the object when they are done. But the first method to do this may end up removing the handle from the marshalable tables kept by both sides, zombifying the other proxies.
If so, this behavior is by design. But we should verify that our docs make abundantly clear that when an RpcMarshalable object is sent over RPC, the sender should truly consider that they don't own the object any more and should certainly not send it again.
Let's review the docs and possibly write a test for this scenario.