


Resultsīased on our logs, 7.414.458 messages where sent to the bot through Telegram, in little over 80 minutes of operation.Īn average of over 380 messages per minute were handled, with a peak of around 1200. Instead of waiting for your server to fetch messages, updates are pushed to your bot’s web server to an URL of your choice (Telegram requires HTTPS, a domain name, and a certificate). Instead of having to deal with parallelism, this mode exploits the inherent strong points of a web server: dealing with multiple incoming connections and handling them off efficiently to your code. This mode-which incidentally is the only mode of operation of many other messaging platforms-trades off the single, efficient data transfer step for multiple parallel message handling operations.

#We need to go deeper bots download
Moreover, after the download phase, data parallelism is entirely up to the developer. Handing off message handling to different threads can be more or less easy, depending on your development framework: in Go a goroutine can be dispatched for each message, while the same can be done for async tasks on any. While transferring one single large payload and performing one single JSON decode step may be more efficient, in pull mode you are indeed increasing the average response time of each message. The Telegram API disallows multiple parallel requests (since, of course, the pull request operates sequentially on the delivery queue). However, pull operations are synchronized by nature. In theory, the pull method ensures higher efficiency: requests are sent out by your server, they can be controlled easily, and large batches of messages can be returned in a single HTTP data transfer. In pull mode, your bot server periodically connects to a Telegram end-point and downloads part of the messages queued up for delivery. The delivery mechanism can be customized, for instance downloading a batch of messages in a single call and using long-polling to stall the request until some data can be returned. Telegram supports two different modes of fetching incoming messages: pull and push. In other words: a lot of messages were sent to our bot over a short amount of time. Since each person could register for a group of people (acting like a team leader), a total number of 9689 people were involved with the game.ġ4 questions were asked, collecting a total of 7004 responses by participants, over approximately one hour and a half. ? Message processingĪ total of 974 participants (in terms of Telegram users) took part in the event. Once invoked, the bot did ask for an answer from the user.Īs soon as the question was closed from our side (by simply providing the correct answer to the bot), the bot did rank all correct answers by timestamp and signal the results on the channel. The first 3 correct answers were publicly acknowledged with various, priceless, emoji medals.
