Avoiding duplicate requests and clarification on timeouts
M
Marco Castorina
started a topic
about 6 years ago
Good evening,
in our game we'd like to make our request calls more robust to issue with internet connectivity (i.e. disconnect or slow mobile connection). To do this, we are planning to queue the requests and, if they fail, try them again. From reading the documentation it appears similar to marking a request as durable, but I am not sure durable requests would cover all cases.
For instance what would happen if a request is send correctly and after that the connection gets lost? In this case I would expect the request to be processed correctly in GS, but the client would never receive the answer. Is there any way to retrieve the answer for a previous sent request? Is this a scenario covered by durable requests?
I also have a question about timeouts: is a timeout triggered if the request is not sent within the time limit or is it triggered if the response is not received within the time limit? Or is the time limit calculated over the request-response round trip?
We are using Unity SDK 5.3.5.209.
Many thanks,
Marco
Best Answer
C
Customer Support
said
about 6 years ago
Hi Marco,
Unfortunately the nature of these requests is that they are dependent on the network to be successful. In the event that a request successfully hits the server, but the client awaiting the response loses connection to the GameSparks service, that response will be lost.
One way to determine response failure due to loss of connection would be to utilize a callback that is triggered after an amount of time past which we can reasonably say the response was lost. Alternatively, you can utilize the timeout response that is generated by the sdk.
Within this response will be an "error" field with a value of "timeout". You can check for this error in the response to determine response failure then handle appropriately. This particular error can be referenced through the following : response.Errors.GetString("error").
Regarding the nature of timeouts. They are determined based on the response rather than a request successfully hitting the server or not. Once it is passed to the websocket the sdk awaits the response rather than monitoring the status of said request.
Let me know if you need any further help.
Best Regards, Patrick.
1 Comment
Customer Support
said
about 6 years ago
Answer
Hi Marco,
Unfortunately the nature of these requests is that they are dependent on the network to be successful. In the event that a request successfully hits the server, but the client awaiting the response loses connection to the GameSparks service, that response will be lost.
One way to determine response failure due to loss of connection would be to utilize a callback that is triggered after an amount of time past which we can reasonably say the response was lost. Alternatively, you can utilize the timeout response that is generated by the sdk.
Within this response will be an "error" field with a value of "timeout". You can check for this error in the response to determine response failure then handle appropriately. This particular error can be referenced through the following : response.Errors.GetString("error").
Regarding the nature of timeouts. They are determined based on the response rather than a request successfully hitting the server or not. Once it is passed to the websocket the sdk awaits the response rather than monitoring the status of said request.
Marco Castorina
Good evening,
in our game we'd like to make our request calls more robust to issue with internet connectivity (i.e. disconnect or slow mobile connection). To do this, we are planning to queue the requests and, if they fail, try them again. From reading the documentation it appears similar to marking a request as durable, but I am not sure durable requests would cover all cases.
For instance what would happen if a request is send correctly and after that the connection gets lost? In this case I would expect the request to be processed correctly in GS, but the client would never receive the answer. Is there any way to retrieve the answer for a previous sent request? Is this a scenario covered by durable requests?
I also have a question about timeouts: is a timeout triggered if the request is not sent within the time limit or is it triggered if the response is not received within the time limit? Or is the time limit calculated over the request-response round trip?
We are using Unity SDK 5.3.5.209.
Many thanks,
Marco
Hi Marco,
Unfortunately the nature of these requests is that they are dependent on the network to be successful. In the event that a request successfully hits the server, but the client awaiting the response loses connection to the GameSparks service, that response will be lost.
One way to determine response failure due to loss of connection would be to utilize a callback that is triggered after an amount of time past which we can reasonably say the response was lost. Alternatively, you can utilize the timeout response that is generated by the sdk.
Within this response will be an "error" field with a value of "timeout". You can check for this error in the response to determine response failure then handle appropriately. This particular error can be referenced through the following : response.Errors.GetString("error").
Regarding the nature of timeouts. They are determined based on the response rather than a request successfully hitting the server or not. Once it is passed to the websocket the sdk awaits the response rather than monitoring the status of said request.
Let me know if you need any further help.
Best Regards, Patrick.
Customer Support
Hi Marco,
Unfortunately the nature of these requests is that they are dependent on the network to be successful. In the event that a request successfully hits the server, but the client awaiting the response loses connection to the GameSparks service, that response will be lost.
One way to determine response failure due to loss of connection would be to utilize a callback that is triggered after an amount of time past which we can reasonably say the response was lost. Alternatively, you can utilize the timeout response that is generated by the sdk.
Within this response will be an "error" field with a value of "timeout". You can check for this error in the response to determine response failure then handle appropriately. This particular error can be referenced through the following : response.Errors.GetString("error").
Regarding the nature of timeouts. They are determined based on the response rather than a request successfully hitting the server or not. Once it is passed to the websocket the sdk awaits the response rather than monitoring the status of said request.
Let me know if you need any further help.
Best Regards, Patrick.
-
Documentation Notes
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2487 topics