HelloA Windows Phone application need to connect to a server and get messages from it. This is done using WCF and long polling on the server. 3 minutes is the timeout defined on the server. Call from windows phone is done using HttpWebRequest.
The problem is that Windows Phone devices have a timeout of 60 seconds for get request (emulator have a different value, greater than 3 minutes).
Currently i can't decrease server timeout. Doing a new GetRequest after the 60 seconds doesn't get anymore messages.
Does anyone have an idea ?
Thanks
I don't think leaving a connection open is a good idea on mobile devices. I'm assuming that's what you're doing. In my app, I would just poll whenever needed by creating a new HttpWebRequest. But it made sense to do this in my app, because I would be updating train arrival status every 40 seconds.
If you're trying to pull data on a given schedule, put a timer in and just call the webserver every 3 minutes or whatever the requirement is.
If you want to be able to check things (when the app is closed) or if there's rarely fresh data on the server, then you'd need to implement a Push mechanism.
Update: Here's a good article on dealing with the timeout issue - http://blog.xyzzer.me/2011/03/10/real-time-client-server-communication-on-windows-phone-with-long-polling/
Update 2: What if you arranged it so that, you have cascading connections - what I mean is since you can't go beyond 60 seconds per connection, you can write a class that'll house two connections and once one of them is about to timeout, say several seconds before, you can start opening the other connection - you can pick the timing so that there's at most 5 seconds of overlap between them. This way you could have your always open connection.
Also see what these guys have done with the GChat app, they have their source code available at this link. This may provide a more proper design.
Related
I have built a react native app/game where a user has 30 mins to finish a task....when they start task, the 30 mins starts to countdown and it is registered in DB (Firebase) that user is "in play". When they complete task (or 30 mins run out) then DB is again updated to "not in play".
Countdown function is operating on phone and not on server.
Problem is that if the user exits the app, then the counter on the phone ceases (the user is no longer "in play") but the DB does not know about it.....there appears to be no "user has exited app" event/handler that I can use to let DB know that user has quit.
I was thinking maybe the countdown logic should be running on backend but I cant think how.....any ideas?
Currently there is no way to handle app terminated in React Native so I think your best shot is to implement it on the backend.
How about when the user starts, you save the time the user started, and if the time difference between now and when the countdown was started surpasses 30 minutes the user is no longer "in play".
One way to detect that the user has left the game would be with Firebase's onDisconnect handler. With this call you register a write operation on the database that is executed when the server detects that the client is gone.
The server can detect this in two ways:
If the client disconnects cleanly, it sends a message to the server that it is disconnecting and the server runs the disconnect handlers for that client straight away.
If the client disconnects in another way, the server will detect that the client is gone when the socket times out, which may take a few minutes.
So in your case you could use an onDisconnect handler to either remove the player from the game, or otherwise mark them as "gone".
The only problem with this approach is that dirty disconnects may take a few minutes, which might be too long for your scenario.
An alternative would be to have the client write a message into the database periodically to signify that it's still here, e.g. a lastUpdated timestamp.
You can then in any code that reads the data use that timestamp to detect if the player was still recently playing, and consider them "gone" after a certain period that works well for your game. This code can then remove the player from the database.
This code can run in a server-side component if you want, but I've in the past also run this type of code in the client and then used (server-side) security rules to ensure it can only remove users that are "gone".
We have an UCWA App that runs as part of a ASP.NET Web Application (as a singleton), and we're using a scheduled job which every two minutes performs reportMyActivity as per documentation; to maintain the application alive and Online.
What we observe, looking at our server logs, is that the application is anyway regularly being shut down by the server, approximately always in about 20 minutes after it was created. During these 20 minutes reportMyActivity returns correctly 204 - NoContent, after that (when going offline), reportMyActivity returns 404 - NotFound instead.
We're also now dumping every event coming through the event channel, and looking at them I don't see any event or evidence being raised; corresponding with the time when UCWA App is being shut down from the server.
We're targeting an on-premises multi-tenant environment.
Any idea or suggestion?
I have an iOS app where I need to load a lot of stuff (JSON data, Images ...) initially after app start (after appdelegate calls the first view). Currently I am using AFNetworking for my requests (Async requests).
What I experienced is a big delay before the first request (3G connection - iPhone 4) itself really starts. I measured the time from operation start to the first bits loaded and checked the answering time of the server. It takes between 2.5 and 4 seconds before the app even starts receiving the first bytes, server said the buildtime is about 0.03 seconds. I think that is a big delay, even if he might have to establish the 3G connection first.
I tested this also with other servers, methods (synchronous/asynchronous), with AFNetworing and simple NSURLRequest and it is always the first request that takes a lot of time.
So my question is, did anyone else experience this and is there a way to accelerate that?
After having my VPS upgraded to CentOs 5.5, I began to experience frozen / disconnected shell sessions if I had neglected them for a certain amount of time. Very annoying. The solution I found was to edit /etc/ssh/sshd_config and set the ClientAliveInterval to the desired number of seconds. My understanding is that this essentially substitutes for activity from the client user (me) and so keeps the session from disconnecting.
Having initiated a shell session after making this minor change, I seem to be able to maintain a neglected session. However, just because a thing seems to be working doesn't mean the best, or even correct, approach was necessarily taken.
Is there a better / different way to prevent a shell session from freezing?
The ClientAliveInterval value can increase the sshd timeout, you can try the following command as well
echo "TMOUT=300 >> /etc/bashrc
echo "readonly TMOUT" >> /etc/bashrc
echo "export TMOUT" >> /etc/bashrc
No guarantees, but this is what I recently started using on the server. 10 seconds seems like a short time, but I don't trust my phone to keep the connection alive. I suppose you could increase the number of seconds till the problem starts again, then dial it back.
ClientAliveInterval 10
Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.
ClientAliveCountMax 200
If it fails, keep trying for about 30 minutes. In other words, keep trying 200x, every 10 seconds. My logic could be flawed though, depending on what happens after 10 seconds. Assuming the client is quiet (like maybe I'm reading) does the "alive" message reset the max count if successful? Is inactivity considered failure? Or is failure a "no acknowledgement" of the alive message? Until I know the answer, I figure it's safe to repeat 200x.
Similar question here, and some decent recommendations...
https://unix.stackexchange.com/questions/400427/when-to-use-clientaliveinterval-versus-serveraliveinterval
I am creating a BREW app that requests the user's position.
If the phone cannot acquire the position, I would like to display an error.
How long should I wait for my callback to be called before I determine that the phone is not likely to get a GPS fix?
When a cold start is required, the receiver has to download a full set of Ephemeris data, which is broadcast from the GPS satellite over a 30 second cycle and re-transmitted every 30 seconds.
So I would say that 60-90 seconds (two or three Ephemeris cycles) would be a suitable time to wait before declaring failure.
http://www.navigadget.com/index.php/gps-knowledge/ttff-time-to-first-fix
Note that if a device requires an almanac download, the startup time can be much longer (on the order of 12.5 to 15 minutes). This is referred to as a Factory TTFF (Time to First Fix).
I might go with an increment (say 20 or 30 seconds) between notifying the user that you have failed to establish a link, and give them the option to stop trying. Keep at it until they stop you, or a set number of iterations have passes (say 5 - 10 iterations).
45-90 seconds.
For more information, see the GPS Time To First Fix article at Wikipedia.
But you can never know when the user actually has view to the satellites or not, maybe they are still inside when they start your program, so the approach suggested by Matthew Vines is much better than a constant delay.
Cellphone-specifically, I've had a Motorola phone that had a GPS receiver, but was horrendously bad at it - it could take it around 5 minutes to get a fix where my standalone Bluetooth receiver would manage in less than a minute.
Why are you declaring failure after a fixed timeout anyway? Why not, after a reasonable time has passed (say, a minute), display a message to the tune of "GPS fix still not available; but I'm still trying" with a possibility to cancel at any time if the user is fed up? What do you expect the user to do with the failure message you're proposing to give him?