Operations vs Events

zumwalt
edited May 2012 in DotNet
So now on to the next phase of this chaos, I am trying to figure out these custom objects of eitehr operations or events then of course custom messages, I have read through the basics pdf on Operations and Events but not sure which is best to use in my case, here is the scenario:

Player enters room, as the player enters, I want there to be something that sends a message to the server that says, give me room objects available, the server will then receive that message, go, ok I need to query the database, does the query, pushes back a list of objects in that room back to the player, the player does something with one of the objects in turn that gets pushed back to the server and the server goes, ok, I need to update the database now.

I was thinking at first this would be an event based iteration, but then after reading the two, this then became in my mind an operation level event, as such knowing databases and players as I do, I will have to mark the objects locked or in use on first hit which is all my stored procedures code working server side. Since this is an N-Tier system I need to ensure proper locks are happening at the right moment.

I also thought about just adding to the player definition a constant for CUSTOM_EVENT=99 or something and pass that with the player then it dawned on me that this is mroe of a broadcast message between players and would do no good at the server level, oui.. out of breath but ultimately is this best handled as a custom operation or a custom event?

Comments

  • Also, in both examples for either Operations or Events, they set the code to 100 but the switch statements use 1 instead of 100 why is that?
  • There is no need for locks as a users stuff is always handled on his fiber which is never multithreaded!
    Also room ops are handled on the rooms fiber, which again are multithreaded.

    all communication between users and users <-> rooms are meant to be done through send message which guarantees that this is not violated.

    Not sure I get the last part. If Photon is meant to do anything but forwarding the message it is a operation (ie server executes some specific code). If its only packet relay to the rest of the room, using an event would be better.

    As for the other question: I'm sure you mixup something there on the level on which it gets interpretated. Also without knowing what base photon application you use (lite, litelobby, mmo or loadbalancing) its generally impossible to say much more here
  • Using Lite as the base which really is overkill since it does more than I needed but I just need to ensure to send the request to the server and response back to that single calling client.

    I tried this as an additive to the player hash table but then all players saw each others results as a broadcast, so going to have to limit this to some sort of custom operation.

    The PDFs that are posted for custom events and operations show the uid as 100 but the used methods have a switch case statement looking at case 1 which is not part of anything in the PDF so it is confusing as o how case 1 is even valid.
  • Don't know about the PDF, I normally just check the Enum in the server code as you will add your own operations likely there too to ensure the crucial 'uniqueness' for the OpCode. Anything else than adding it there would be 'good guessing' or would remove the possibility to easily go to future versions as the opcodes changed already once during the 3.0 RCs

    As for the 'result being broadcasted': Thats a thing you operation would need to do explicitely in the server side code so its easy to correct when you check to which peer you send the event with the response (unless you use the operation response directly if its nothing that requires 'too long' or further asyncronous code to generated the required answer)
  • We had a bank holiday weekend here, so excuse the delayed reply.

    Operations are more or less the same as RPCs on the server. It's something the client calls to make the server do something. They might have a result and some trigger events. A result is something sent to a client as reply for a operation call but not necessarily immediately. An event is some message to a client or multiple clients. It's either coming from another client or the server for some reason. Photon can send an event to a single client, too, even if it doesn't use a room.
    The Lite application logic handled operations either in the LiteGame or the LitePeer class. The LitePeer affects only one client (it's the client's representation) and if a operation gets forwarded into a Room (LiteGame), it might affect anything in that room.

    So you can choose where you handle an operation and reading your posts, I can only recommend you to use Lite. It solves a few issues you won't have on the map so far.
    In your case, I'd create a new operation and define an event with the data. Make the operation return "ok" when the DB is available and everything works nicely. Then send the data as event when the DB fetch is complete. This de-couples operation call from the result.
    You should think about which data multiple users need. If you update all players of a room when someone uses something, then a room-wide event is ok. Then look at OpRaiseEvent in the server side.

    As for codes: Maybe they are outdated in the PDF. Take a look at the code - that's always been more important to us.
    Lite has a basic server / room logic. For that, we defined a few operations and have to assign operation, event and error codes as well as parameter codes. Anything that defines a RPC has a byte code in Photon (to keep it small, not simple).
    In Photon 3 we cleaned "our" codes and made them start at 255 and go down. Your codes can always start at 1.
    Demos are just that: Demos. You can ignore their codes and assign a new meaning to them.
  • Thanks for that explanation means worlds to me, now I can see the difference in the samples, will let you all know if I get this wrapped around in my head and working.