@hoboadam_psn said in Here's what I think is happening with the servers.:
@joshq00_psn said in Here's what I think is happening with the servers.:
The real solution would be have more server interactions - best case you don't lose an at bat or a strikeout. Not to make it difficult to get your progress to save on number of requests made. Solving the scalability problem is more pressing than finding ways to make fewer interactions
There are server interactions after every AB. That's why dashboard HR don't register but the previous SB does.
Two clients are sending data when the game gets dashboarded. Reconciliation occurs and defaults to the last event validated on both clients. The previous AB.
There used to be issues last year not noticed by the community. Sometimes client A would send an error, client B a hit. Also the instance where a run would score when an out was made at a base concurrently when advancing a runner. You'd win 3-3. The opponent would show a 4-3 loss and vice versa.
Exactly. Dashboarding only works within a few seconds and the only reason it can't be recorded immediately when the game determines the outcome is because there's possibility for it to be stolen. You get updates on each move your opponent is making in the outfield. The servers need to handle every action (think of a FPS where every bullet, turn, movement have to be communicated real time). Horizontal scalability was an afterthought, yet again, and it's what's needed to handle scale. These aren't mainframe days, these require real-time messaging with post processing and scalability. It's not about finding where you can cut down on information