RPC Question

I've decided to embrace the photon cloud to ease client development then "port" over to an athorative server for launch using a MVC-ish separation of code that delegates business logic to the master client. So far so good.
:mrgreen:
  • client requests an action from master client
  • master client resolves outcome of action (but how can it be sure the rpc's origin is not spoofed?)
  • master client broadcasts result to all clients

I'm trying to "authenticate" the origin of an rpc in a way more intuitive than just passing it as an argument.
I was wondering if an arbitrary photon [RPC] is automatically provided with it's origin as an optional argument. I understand that I could just reference the peer in the params[], so this is more of a best-practice question.
:|

Comments

  • The sender (actorNumber) of anything is always part of anything sent. It's supplied by the server, not by sending clients.
    This is what's used for the last, optional callback parameter.

    As you plan to move on to an authoritative server:
    PUN's way to call RPCs is not really supported by the server. It's similar of course but the server does not have a Unity-alike PUN framework, so it doesn't know (yet) which game objects and photon views are existing.
    If you build everything on top of PUN first, then you will have to replicate these features on the server or refactor your client to our operation/response/event framework.

    You should take a look relatively early on, of use your initial project as proof of concept, then switch to our server.
  • Thank you for such a quick reply.
    To clarify,
    • sender is used by an athorative server, but not a master client.
    • For now, I should just pass sender as a param[].
    • I'll need to rewrite more than expected.

    Do you think it's really worth it to use the cloud for development? Or should I use the Photon server as soon as possible?
  • You could run a Unity instance per game as authoritative server but that's probably some overhead and also requires some additional work to start instances as needed, etc.

    If you want server-side logic, I guess it makes sense to switch soon to the plain (non-PUN) Photon Loadbalancing API client-side and then get into server side coding as well.
    PUN is so different that sooner or later you have to solve problems that only exist with the PUN setup (randomly hosted server on some user's machine). When switching to an authoritative server in Photon, this work would be lost.
  • Confused...all this time I'd been using PUN with a photon server hosted on a VPS... being confused trying to figure out if I wanted to define an RPC or an operation.
    :?
  • Operations can only be called from client to server. Not on another client.
    PUN has RPCs which call a method on another PUN client but not on the server.

    If you want extensive server side logic, you should try to get there without PUN.