I have joined a bot in a group to archive the messages. I'm coding a php code for archiving, till this get complete, I manually getupdates from the browser. and save the results in a text file. and frequently I use offset to get newer msgs. but next time when I getupdates after offset (for example one after that) I see that I have a jump! for example if the last id was 1500, after getupdate I see 1553 or 1540, and I donn't see the msgs in the gap. anyone can help me,please?
I may be because old updates are deleted if not requested in a period of time (about 24 hours).
From https://core.telegram.org/bots/api#getting-updates:
Incoming updates are stored on the server until the bot receives them [...], but they will not be kept longer than 24 hours.
What I am not sure is if the lost updates consume update_id values.
Related
We've recently started adding programmed radio to our existing SMAPI implementation. I've followed the Sonos Developer documentation and (eventually) got it working as expected. I'm just seeking for some clarification around the 'auto updating' based on the 'queueVersion' value.
Our schedules which are feeding the programmed radio can change from time to time. These changes should be reflected on the Sonos Players as soon as possible. For what I understand this should be possible by modifying the queueVersion property in both GET /context, GET /itemWindow and GET /version.
Looking at the GET /version documentation I see that Players "[...] are responsible for periodically polling this [QueueVersion] value to detect changes in the cloud queue track list, [...]".
I've monitored our API logs for about 15 minutes in which I would expect at least a GET /version request, but none showed up. The only calls I'm seeing are POST /timePlayed.
Can anyone (from the Sonos team perhaps?) clarify what this interval is set to, or how it can be controlled?
Given that you aren't seeing GET /version requests, there may be an error in your configuration.
The player sends a GET /version request every 5 minutes when paused and every 10 minutes when playing. This is by design, not depending on any setting that you can control. However, players fetch new tracks as needed using GET /itemWindow. The player requires a version in your response, so it doesn't send a GET /version request in this case. After the player gets a new item window, it resets the polling interval to another 10 minutes.
See the Play audio (cloud queue) page for details.
So I'm trying to understand what practical problems Queues solve. By reading all the information from Google, I get the high-level.
Push message to Queue for processing at a later time
So I'm looking at an architecture from Company A and they have different use cases for Job Queueing like for example
chat messages
file conversion
searching
Heavy sql queries
Why process it at a later time?
Here's my best guess...
Let's say I have an application that can process 10 "things" at a time.
My application then maxes out it's processing capacity.
an 11th request came in so app puts it in the Queue for later processing
Assuming this is a valid Use Case, wouldn't adding more servers to process more "things" make sense? Is it because it's more costly to add more servers than employ a Queue and sacrifice response time a little bit?
Given my Use Case examples, what other problems would Queues solve for them?
Have you ever lined up at a bank when it is busy? You would have waited in a queue.
"But," you could say, "wouldn't adding more staff to process more customers make sense? Is it because it's more costly to add more staff than employ a Queue and sacrifice response time a little bit?"
That would be correct. It can be quite costly to staff a bank based on the peak number of customers who would arrive each day. It is cheaper to staff below this level and have some customers wait in a queue.
Also, the number of customers each day are not 100% predictable. A queue allows excess demand to wait without breaking the system.
Queues enable decoupling.
For example, imagine an online store where customers purchase an item. They select the item, provide a credit card number and click 'Purchase'. If the credit card is declined, the online store can immediately prompt them to re-enter the number. This interaction has to take place immediately while the customer is still online.
However, there is no need to have the customer wait while an invoice is generated, a record is added to the accounting system and inventory is pulled off the shelf. This can be decoupled from the ordering process. A good way to do it is to push the order into a queue, which can be handled by the next system.
If that 'next system' happens to be offline at the moment, there is no reason to cancel the whole sale. The transaction can be processed when the 'next system' comes back online. This is much better than failing the whole process just because one component (which is not required immediately) has a failure.
Bottom line: Queues are excellent. They enable better handling of failures. They makes things more resilient (just wait a few minutes and try again!). They should be used at all times when the process is compatible with a queuing architecture.
Let's do scenarios
Scenario 1 without queue:
you request an endpoint /blabla/do-eveything/
this request do
download an image from very slow FTP
e.g 1.5 sec (can error, retry ? add +X sec)
attach the image to an email
send an email (3 sec)
e.g 1 sec (can error, retry ? add +X sec)
confirmation received > store confirmation to a third company tracking stuff
e.g 1.5 (can error, retry ? add +X sec)
when tracking confirm, update your data from another third company for big data purpose
e.g 2 sec (can error, retry ? add +X sec)
... you get the idead
return the response e.g 11 sec later (this is to slow) or more or timeout when everything failed
End user said internet was faster 20 years ago, maybe I need to change my internet connection or change my 16 threads
Scenario 2 queue everything you can:
you request an endpoint /blabla/do-eveything/
this request do
Queue job "DO_EVERYTHING"
e.g 0.02 sec
Return the response less then 0.250 sec
End user said that is website/app is too fast, I can keep my 56K internet connection
on queue/event system one failed job can be retry later without affeting the end user
you can pause job, add a unlimited number a task/step after the original message
better fault tolerance
Working with queue will allow you a better micro/nano service architecture, better testing because, you can test a single job, intead of a full controller that do everything...
Ye, is maybe more work, more thinking, but a the end no need to think about the work when holidays
I have a stream url like https://www.twitch.tv/streams/26114851120/channel/31809543. Stream is online and I need to catch moment when stream will be finished.
I researched twitch api documentation and didn't find any events. The first thought was to send requests every several minutes and when stream going online - handle this. It was a little delay, but it isn't critical.
But there are many streams that I must track and I scare that twitch can block me for this.
Are there any other ways to catch stream's finish?
As best I can tell there's no way to directly listen for a stream going online or offline, but you can still monitor a large number of streams in spite of that.
There are a fair number of Q&A on the official Twitch developer site wanting this functionality, but all of them I could find are answered with the same "it's not currently possible."
Keep in mind that you can check the status of multiple channels simultaneously (up to 100 per request) using a comma separated list and the limit query parameter: Get-Live-Streams
https://api.twitch.tv/kraken/streams/?get-live-streams?channel=Channel1,Channel2&limit=100
That'll return an object containing an array of online streams (the streams property).
Rate Limits
Twitch's official stance regarding rate limiting is a recommendation of no more than "about 1 request per second". That said they don't throttle you for making several requests in immediate succession, but rather the cumulative amount.
Note that there's a separate rate limit for IRC-related actions of 20 commands/messages per 30 seconds normally or 100 per 30 if a mod. Violating that will trigger a 30 minute lockout.
API-Side Caching
API results are also cached for 1-3 minutes which reduces load on their end. Given that, there's not much value in polling for anything more frequently than that (i.e. you should wait at least 1 minute before making the exact same request again since you'd just get the same response).
You Can Still Monitor ~6000 Streams
Given the ability to check 100 streams at a time, a need to wait for at least 1 minute per request to get new results, and an approximate rate limit of 1 request per second, you can theoretically check the status of about 6000 streams continuously (assuming you're not making other requests; 100 streams per second * 60 per minute).
PubSub For Monitoring Other Things
Currently the PubSub API doesn't have anything for monitoring stream's going online, but you may want to keep it in mind for other polling-type actions (it currently deals with things like new subscriptions or donations).
Using The Embedded Player
One last thing worth noting is you can listen for a channel going online or offline when you're using the Twitch Embedded Player.
Might be a little late to reply, but now you can look into Twitch WebHooks.
They allow you to subscribe to specific stream(s) to have Twitch notify your callback URL, when stream goes up or down.
This seems more accurate and bandwidth-saving than querying twitch yourself.
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.
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?