Process OperationRequest outside of RequestFiber?

Options
BesoC
BesoC ✭✭
edited September 2014 in Photon Server
Hi

The situation:
1. All client requests are running (e.g. scheduled) in RequestFiber.
2. We have implemented a simple 'disconnect check' procedure - client sends 'Ping' operation to server and server responds.If there are no responses within 5 seconds, client disconnects itself and then tries to reconnect.
3. There are a couple of operations that, under certain circumstances, can take more then 5 secs. In such situations client is actually connected, but as long as there are no responses from server, client disconnects.

My question is - is it possible to process certain OperationRequest - 'Ping' outside of RequestFiber?

Any other suggestions?

Thanks in advance

Comments

  • chvetsov
    Options
    Hi, BesoC!

    no, it is not possible. All user operation requests are handled in RequestFiber. That is why they should be handled as fast as possible or you should handle them in another firber or thread.

    I would say that if operation takes more then 5 sec for processing than defenetly something is not right. you should process them outside of RequestFiber.

    Sugestion: may be it will better for you to use PhotonPeer.TimestampOfLastSocketReceive, you may check when you get last time anything from server or if you are using UDP you may set PhotonPeer.DisconnectTimeout
  • BesoC
    Options
    Hi Ilya

    Client side is using Flash, there is no TimestampOfLastSocketReceive in Flash SDK unfortunately. BTW, are you planning to update flash client?
  • Hi BesoC,

    I'm not a Flash expert (or a Client SDK expert in general), but as far as I know, all clients have a built-in disconnect check and do a low-level Ping automatically. Maybe you can just get rid of your custom disconnect check? (For details, please open a separate thread in the Flash SDK forum so that the Flash SDK developer can have a look).

    As Ilya explained, all operations are put into the RequestFiber automatically by Photon. That is our way to ensure that everything is executed "in order" and to avoid multithreading issues in the peer class.

    What you can do:
    Inside the ExecuteOperation() method, spawn a new thread and move the execution of the long-running requests there. This way, the RequestFiber can continue to execute the next operation in parallel.

    If you choose that approach, you need to take care of potential multithreading-issues yourself, of course.

    PS: due to low demand, the Flash SDK doesn't have high priority and we don't plan any major upgrades in the next time. Sorry. :/
  • BesoC
    Options
    Hi Nicole

    You are correct - there is a low-level ping in Flash client, as it was stated inf appropriate forum. The problem is that sometimes Flash client is connected but not receiving anything at all. That's why I need to add extra check... I ended up with sending pings from server - this way it not interferes with peer's RequestFiber.

    Pity that Flash client is not evolving, there are a lot of features in C#/Unity client that we're missing in Flash.....