Open FourierTransformer opened 9 years ago
I can't replicate either atm (rebooted and freshly built - it might've just been a local resource-related issue). I'll keep this open for a bit in case anyone notices something related to this.
I've noticed a timing issue.
Me too, when running against Azure. None that I noticed when running locally. Have you guys ensured the C# agent is actually using web sockets (inspect signalR transport property)? It took me a bunch of tries to really get web sockets working with a console app and Azure.
edit: nvm, not using signal r
I think it is the client not accounting for network latency and going out of step with the server clock. The demo client needs to adjust more intelligently...
The old code was issuing POSTs in serial (foreach
).
We tried switching to POSTing in parallel and it seemed to fix the problem (eliminating serial roundtrip time):
CSharpAgent AgentBase.cs
protected async Task<List<MoveResult>> SendUpdate(List<MoveCommand> moveCommands)
{
var results = new List<MoveResult>();
foreach (var moveCommand in moveCommands)
{
Console.WriteLine(string.Format("posting move {0} for elevator {1}", moveCommand.Direction, moveCommand.ElevatorId));
}
var responses = await Task.WhenAll(moveCommands.Select(mc => _client.PostAsJsonAsync("api/game/move", mc)).ToArray());
foreach (var response in responses)
{
results.Add(await response.Content.ReadAsAsync<MoveResult>());
}
return results;
}
If you set the timing options to:
You'll generally get a
Server is processing, please try again soon
- which doesn't make sense. The error appears in less frequency ifTURN_DURATION
andSERVER_PROCESSING
are similar (if you set them both to 200 or 500, most of the time it'll work correctly). Also, it seems possible to just spam the server with move requests and prevent players (it might just be your opponent, I haven't looked into this much) from moving entirely. I'm thinking we should abort a player if they issue to many move requests per turn, as they are likely cheating.