chbfiv
commented
10 years ago Adding NOTES for additional discussions
Does the SDK handle any retries on connection failures? [11/19/2013 2:28:41 PM] drjcyang: Right now the SDK doesn't [11/19/2013 2:29:30 PM] drjcyang: We could probably add in a "# retry option" or something [11/19/2013 2:29:44 PM] drjcyang: After this SDK we are planning to implement caching [11/19/2013 2:30:01 PM] Dave Calla: yeah, a # retry would be what I'm looking for [11/19/2013 2:30:28 PM] Dave Calla: and after it fails x number of times, it returns the failure to my client…at which time I tell the user that their connection is borked [11/19/2013 2:31:36 PM] drjcyang: ok, you mind putting that on github? [11/19/2013 2:31:52 PM] Dave Calla: sure [11/19/2013 2:32:16 PM] drjcyang: what about saving state like during a pause? [11/19/2013 2:32:38 PM] drjcyang: or I guess what happens if the connection fails? should the sdk keep the call around? [11/19/2013 2:34:34 PM] Dave Calla: if the connection fails, I think I'm just going to tell the client that their connection has been lost, and they'll need to try again later... [11/19/2013 2:35:06 PM] Dave Calla: when the come back to the app, I'll repull all their progress and it'll be at the state at which it was before the request was sent [11/19/2013 2:35:16 PM] Dave Calla: *when they come back [11/19/2013 2:36:04 PM] drjcyang: so the SDK shouldn't be responsible for keep the call until you get your connection? [11/19/2013 2:36:41 PM] Dave Calla: I'm leaning towards no. The user can just reinitiate that request when the connection is good again [11/19/2013 2:36:49 PM] Dave Calla: thoughts? [11/19/2013 2:38:14 PM] drjcyang: we can do another round of discussion, but we may want to replay things like sending receipts to make sure it really goes through [11/19/2013 2:38:52 PM] Dave Calla: yeah... [11/19/2013 2:40:41 PM] Dave Calla: all requests will have to be serial. Say a user makes 2 requests. Request A fails due to bad connection, well then Request B will need to be rejected from the server regardless of connection. [11/19/2013 2:40:43 PM] Dave Calla: right? [11/19/2013 2:41:23 PM] Dave Calla: and in that scenario, both requests were initiated by the user before Request A returned [11/19/2013 2:41:41 PM] Dave Calla: sorry, more clearly, Request B was initiated before Request A returned [11/19/2013 2:41:59 PM] drjcyang: ok, we aren't doing that checking [11/19/2013 2:42:07 PM] drjcyang: At least you can't tell on server that is happening [11/19/2013 2:42:10 PM] drjcyang: it would have to be an SDK thing [11/19/2013 2:42:49 PM] drjcyang: but then again with async calls should you guarantee ordering? [11/19/2013 2:45:36 PM] Dave Calla: I think we'll absolutely have to have guaranteed ordering. Your semi-generic InvestExpress server server can't be the authority on all Game related requests. [11/19/2013 2:46:50 PM] drjcyang: I guess the question is who is responsible for enforcing that policy the dev, the sdk or the server? [11/19/2013 2:46:59 PM] Dave Calla: the ordering policy? [11/19/2013 2:47:04 PM] drjcyang: yeah [11/19/2013 2:47:17 PM] drjcyang: if I have autonomous units harvesting stuff for example, I don't care about ordering [11/19/2013 2:47:21 PM] drjcyang: I understand what your'e saying [11/19/2013 2:47:27 PM] drjcyang: and it makes sense [11/19/2013 2:47:47 PM] Dave Calla: If the SDK just kept an ordered queue of requests, and sent them async when the previous one returned successfully, that would suffice I think [11/19/2013 2:47:58 PM] drjcyang: right that was what I was thinking [11/19/2013 2:48:04 PM] Dave Calla: we def can't use the sync version because we don't want to be waiting on server operations for EVERYTHING [11/19/2013 2:48:23 PM] drjcyang: no I get that but what if some things don't require ordering? [11/19/2013 2:48:31 PM] Dave Calla: k, yeah lemme think [11/19/2013 2:48:42 PM] drjcyang: do I invalidate all calls and have to force the dev to replay? [11/19/2013 2:48:58 PM] Dave Calla: yeah, that's what I was thinking [11/19/2013 2:49:20 PM] Dave Calla: as soon as one fails, kill the queue, tell the app that the connection is bad, and the user will need to reconnect [11/19/2013 2:50:05 PM] Dave Calla: and the user will "lose work" that was done during and after the request that failed [11/19/2013 2:50:40 PM] Dave Calla: I even think things like harvesting require order [11/19/2013 2:50:44 PM] drjcyang: or we have a enqueue call [11/19/2013 2:50:53 PM] drjcyang: so sync, async, queued [11/19/2013 2:50:57 PM] Dave Calla: because if I harvest then plant in quick succession, the plant will fail [11/19/2013 2:51:19 PM] Dave Calla: if it was handled before the harvest [11/19/2013 2:51:37 PM] Dave Calla: actually, it won't fail [11/19/2013 2:51:50 PM] Dave Calla: it'll leave the game in a potential bad state [11/19/2013 2:51:58 PM] Dave Calla: with possibly 2 crops on one plot or something [11/19/2013 2:52:04 PM] Dave Calla: if the original harvest failed for whatever reason [11/19/2013 2:52:31 PM] drjcyang: I guess if you fail the harvest and suecced the plant, you could lose all your seeds? [11/19/2013 2:52:43 PM] Dave Calla: You shouldn't [11/19/2013 2:52:49 PM] drjcyang: I mean I understand what you're saying [11/19/2013 2:53:00 PM] Dave Calla: yeah, and I see what you're saying [11/19/2013 2:53:11 PM] drjcyang: it's really about who enforces policy [11/19/2013 2:53:16 PM] drjcyang: it has to be either dev or SDK [11/19/2013 2:53:19 PM] Dave Calla: I think the SDK :) [11/19/2013 2:53:38 PM] Dave Calla: if it's not the SDK, I'd have to keep my own queue of requests to feed the SDK [11/19/2013 2:53:41 PM] drjcyang: other option we've been thinking is having a "helper" class [11/19/2013 2:53:44 PM] drjcyang: so not core sdk [11/19/2013 2:53:53 PM] drjcyang: or utilities rather [11/19/2013 2:54:05 PM] drjcyang: so things that could help but might not want to sit on the sdk [11/19/2013 2:54:10 PM] Dave Calla: sure sure [11/19/2013 2:54:25 PM] drjcyang: for example I've been thinking this load/save thing we've been doing for user shouldn't be in core [11/19/2013 2:54:41 PM] drjcyang: because there are potential other requests and use cases we aren't covering [11/19/2013 2:54:57 PM] drjcyang: or another example if we want to provide events [11/19/2013 2:55:18 PM] drjcyang: so for your scenario maybe we can add a queue as a utility [11/19/2013 2:55:42 PM] Dave Calla: right, your utility would fill in where I'd have to otherwise write my own queue system [11/19/2013 2:55:45 PM] Dave Calla: that could work [11/19/2013 2:55:55 PM] drjcyang: ok, let me discuss with bourke [11/19/2013 2:56:04 PM] Dave Calla: I'm trying to think if it really shouldn't be part of the SDK proper though [11/19/2013 2:56:18 PM] Dave Calla: I think most things I can think of, I'd want to call the asycnQueued version [11/19/2013 2:56:48 PM] drjcyang: well for a WWF style most the time I probably don't care [11/19/2013 2:56:56 PM] Dave Calla: maybe if I was making a cookie clicker game…I wouldn't' care if one click didn't succeed [11/19/2013 2:57:01 PM] drjcyang: it refreshes when it refreshes [11/19/2013 2:57:19 PM] drjcyang: as long as the match made it through it's all good [11/19/2013 2:58:02 PM] Dave Calla: yeah…I wouldn't care that game A refreshed before game B... [11/19/2013 2:58:17 PM] Dave Calla: in a WWF "refresh all games" situation [11/19/2013 2:59:21 PM] drjcyang: so for an invest express, I would impinge that every object in production has it's own timer checker [11/19/2013 2:59:27 PM] drjcyang: which doesn't require ordering [11/19/2013 3:00:08 PM] Dave Calla: every object that's 'in production' does have it's own timer [11/19/2013 3:00:30 PM] drjcyang: right but the only thing that requires ordering is the timer check and harvest calls [11/19/2013 3:00:39 PM] drjcyang: hypothetically here [11/19/2013 3:00:44 PM] Dave Calla: sure sure [11/19/2013 3:00:45 PM] Dave Calla: thinking [11/19/2013 3:01:01 PM] drjcyang: two objects timer check doesn't require order [11/19/2013 3:01:20 PM] drjcyang: this could get complicated if you wanted to make it fancy [11/19/2013 3:01:24 PM] Dave Calla: timer check happens on the client only…no? [11/19/2013 3:01:39 PM] drjcyang: this is just a theoretical situtaion [11/19/2013 3:01:46 PM] drjcyang: off the top of my head [11/19/2013 3:02:11 PM] Dave Calla: right, I'm thinking about when any in production object would be sending a request to check it's timer [11/19/2013 3:02:44 PM] Dave Calla: it might be related to "killing" a push notification..? [11/19/2013 3:02:50 PM] drjcyang: sure, i'm just trying to illustrate that not all things require order [11/19/2013 3:03:04 PM] Dave Calla: yeah I'm sure there are situations [11/19/2013 3:03:08 PM] Dave Calla: but there are plenty that do [11/19/2013 3:03:26 PM] drjcyang: i could even see people wanting to have multiple queues [11/19/2013 3:03:39 PM] drjcyang: so maybe the utility makes sense [11/19/2013 3:03:41 PM] Dave Calla: yeah, I can see that
Implement an auto retry x number of times. After the request fails x number of times, the SDK returns the failure to my client…at which time I tell the user that their connection is borked