Delaying SendOperationResponse

escjosh

Is there anything wrong with the following chunk of code? What happens if the peer (and its RequestFiber) are disposed or disconnected before the function is executed? What if it were enqueued on a different fiber that was unrelated to the peer?

protected override void OnOperationRequest( OperationRequest operationRequest, SendParameters sendParameters )
{
	var response = new OperationResponse
	{
		OperationCode = operationRequest.OperationCode,
		ReturnCode = (short)OperationReturnCode.OperationInvalid,
	};

	// Send the OperationResponse one second from now.
	RequestFiber.Schedule( () => SendOperationResponse( response, sendParameters ), 1000 );
}	

This is just using an empty OperationResponse as an example. In my actual code, I want to do some real work in the lambda function that may take a while.

dreamora

You need to execute the response directly so the client knows about it.
You can schedule your lambda and make it send an event to calculate and execute the data asyncronously to the operation itself.

escjosh

Ok, thanks.

Out of curiosity, do you know why? I mean, the whole exchange is asynchronous, so why does it matter if the response takes an extra 200 milliseconds to arrive?

If it makes a difference, I'm doing all of this in the context of server to server, not with a game client. So there's no UI or lag problem - the server calling SendOperationRequest doesn't really care how long the other server takes to call SendOperationResponse. I'm just wondering if there's some technical or photon-internal reason that I shouldn't do that.

escjosh

Also, I still need to know what happens to actions that are scheduled to run on a peer's fiber when that peer is disconnected or disposed.

In fact, I'm not really sure when Peers are disposed by Photon. Is that documented somewhere?

escjosh

For future reference, it appears to be OK to delay SendOperationResponse. See MmoActor in the mmo demo code, where the call to SendOperationResponse is frequently queued on a fiber to happen later.

Tobias

If you schedule the response, it should be perfectly fine. Everything else keeps running and nothing's blocked. In fact, the operations (and thus their responses) rely on this very system.
Alternatively you could respond immediately and provide additional results in an event. This shifts things a bit towards ignoring results and waiting for events but your solution is very similar.

escjosh

Great, thanks again Tobias.