Is there a nice way to get any kind of caller information

[1knueller]

Hi!

Is there a elegant way to get caller information in a rpcfunction?
when im adding as local target instance implementing my contract for many clients?

AKA:

connecting like this:

                var handler = new LengthHeaderMessageHandler(pipeStream, pipeStream, RPCFormat.GetFormatter());
                rpc = new JsonRpc(handler);
                rpc .AddLocalRpcTarget<IRPCServer>(MyServerSingletonInstance,null);
                rpc.StartListening();

having interface and impl like this:

interface IRPCServer
{
  void YouShouldKnowMe();
}

class MyServer : IRPCServer
{
  IRPCServer.YouShouldKnowMe()
  {
    var CallerNameORRPCInstanceOrSo = InsertSmartThingToIdentifyCallerHere();
    print("i know you through: CallerNameORRPCInstanceOrSo ")
  }
}

[AArnott]

JSON-RPC has no authentication protocol at all.
But presumably when you made the connection with a client in the first place, you had an opportunity to identify the client. When you know who the client is and you set up the RPC connection for them, on the server side you can construct your server object with a constructor parameter that identifies the client and then in your server methods, you always know who the client is by checking that field.

[1knueller]

yes, using one object instance as local target for every rpc connection makes this puzzle easy.
I hoped there was a elegant, smart implementation for a single object instance called by multiple different RPC clients.

I tried to implement sth like the Context that is being used in ASP with a static AsyncLocal and setting that with a custom IJsonRpcMessageHandler (just to explore the concept)

A bit more nice to look at variant would be something else I thought about.
An implementation through an attribute like so: (for the RPC contract)

public Task MyFunction([MyServerInjectValue] JsonRPC rpc = null)

Its optional so on the client side i can call proxy.ClientFinishedJob() without providing anything.
And on the server we see the attribute and know that this one one I have to fill from.

not sure where could be a nice place to implement this - if there is one.

This could have a valuefactory associated with it and that knows its RPC object so we can do whatever (simply map it from a dictionary) OR it could also reference another proxy that lives on that rpc object (making it easy to tie identifying logic/objects/data to it) because its more customizable, and doesnt pass that rather heavy (in terms of references) object around and would let me have sth small like a object with 3 string values on it.

public Task MyFunction([MyServerInjectValue] MyRpcInformation rpc = null) where that is an object that I can create from the connection that gets some kind of caller context so i know everytime wich one i have to pass to the function....

but at this point the cost of the complexity does not really make sense compared to just passing whatever i want from the child....

tbh, a simple "optional Guid as function param" that identifies a RPC session would be enough to do anything without too much change.

[AArnott]

yes, using one object instance as local target for every rpc connection makes this puzzle easy.
I hoped there was a elegant, smart implementation for a single object instance called by multiple different RPC clients.

Why? If one target object per client makes this easy, what alternate solution could be more elegant?

I strongly advise against using ExecutionContext (e.g. AsyncLocal) for this. ExecutionContext has a tendency to leak to places you don't mean for it to, and to be dropped unexpectedly. Not that it's unreliable, but it's very subtle, and it relies on particular patterns being used that aren't reliably recognized by engineers. As a result, you could end up misrepresenting who the client is and make bad privacy or security decisions based on that.