Guidance on preventing floods

[DaleSchultz]

I am aware that at some threshold, a Blynk server will disconnect so that it does not get flooded by messsages.
I am aware I can install a local server and set my own threshold.

At https://github.com/blynkkk/blynk-library/blob/master/src/Blynk/BlynkConfig.h#L42
I have managed to glean that BLYNK_MSG_LIMIT defines a limit per second.

// Limit the amount of outgoing commands per second.
#define BLYNK_MSG_LIMIT      15

What I can’t work out is if that limit is being implemented locally on the processor or at the server side. My guess is it is on the client side.
What does the client do if the threshold is exceed, does it just skip the additional calls?
What time period does it use for measuring the rate (which may not be the same as the units of the setting). Posing the question slightly differently, what order of magitude is used, eg, is it measured over 10ms, 100ms, 1s or 10s?

Similarly, on the server side, is the threshold policed over a few seconds (and averaged) or is the disconnection made if there is any burst that exceeds the rate? How many consecutive call will exceed the threshold. (Yes I could just try it but I don’t want to cause floods by testing, unless that is OK with Blynk.)

What is the acceptable rate of digitalWrites and setProperty calls?

Background
I have an app with 4 lights, three of which use timers to transition brightness settings. I plan on enhancing the code to reduce the number of PWD changes made to the lights during fast transitions as I doubt the human eye needs, or can event detect, brightness changes at even 10Hz.

Each time I change a light, I update the app with a digitalWrite.
Some events in my app will make 3 consecutive setProperty calls

If the user elected to move all 3 dimmable lights from 0 to 100% over one second, the worst case scenario would be 303 calls in a second if I left my code as it is (making a change for every percentage change).

I have not had any flood disconnects yet, so I am looking for more information on this before I alter my code to reduce the rate of changes, and decide if the digital writes will need a slower rate than the actual pin changes being done.

[Gunner]

@DaleSchultz

What I can’t work out is if that limit is being implemented locally on the processor or at the server side. My guess is it is on the client side.

Since most devices can crank out thousands of cycles a second as is done in non-IoT applications, I suspect it is the server side as that is where the effects are most notable… thus the settings in the sketch prime the servers settings within its limits. Although as mentioned further below, there is also a possibility of some device /library side “governing”

@DaleSchultz

What is the acceptable rate of digitalWrites and setProperty calls?

Since Blynk is an IoT application much is dependent on the network throughput, but there are some references to recommended limitations in the documentation.

Introduction

As with the ebb and flow of any variable medium, Cloud Server, network traffic, processor load… if it works stable all the time then you got it dialed in, if it doesn’t then you don’t trial and error within the recommendations is you only real option to determine the best settings…

But if you really want control, then a Local Server will eliminate much of the bottleneck.

@DaleSchultz

I have not had any flood disconnects yet,

Blynk implemented some “governor” like changes early last year that help mitigate the disconnections… They never stated how, but probably by simply dropping some of the rapidly incoming signals… although I did notice a reduction of void loop() cycles in my sketches when that happened.

You can read and search for further info of this…

Library 0.5.0 Anti-flooding methods seem to affect void loop() and timer consistency

I just wanted to bring this little 'fix" up again as I finally tracked it down as the culprit to one of my large code testbed projects randomly dropping into a repetitive round of rebooting. It seems that this fix, when it encounters a large influx of Blynk commands… somehow hijacks the void loop() to the point that, instead of thousands of cycles per second, it is only processing as many as needed to process the Blynk commands… Once I made up a check routine to monitor whatever was going on, …

[DaleSchultz]

yes thanks, I read that thread and the docs beforehand, hence my questions, which still stand.

[Gunner]

@DaleSchultz

I read that thread and the docs beforehand, hence my questions

I think you will find that the developers are more interested in developing then sharing all their secrets But as far as the Libraries and Local Server code, it is all open source, so they generally inform and welcome curious users to dig in and find the answers, and/or “custom fixes” if needed, on their own.

@DaleSchultz

which still stand.

And why wouldn’t they?

FYI, I generally comment on topics like this to help generate interest and feedback… otherwise I have seen that they often just get

But if you are not interested in feedback then I will ignore it as well…

[DaleSchultz]

unless the questions are not been answered in any way, others may think the questions have been answered. Only once one wades through all that can realize that the questions are still unanswered.

Your wisdom and experience is invaluable, but you cant be expected to know all the answers.

[Gunner]

Now that is a lyrical conundrum

[DaleSchultz]

some experimenting shows that 50ms delays between brightness changes do not seem to produce perceptible changes to my eye. (Tested just with some LEDs connected to a breadboard, full scale room lighting may be different.)

So three light systems dimming from 0 to 100% at the same time would result in an average rate of about 16ms.
If the maximum rate is 1 every 10ms that should not exceed the flood rate, if it is measured over 1s.

[DaleSchultz]

why is this marked as Solved now? This is solved when the information being asked for has been provided.

We know there is a rate, but we do not know the time period of which the rate is measured.
Like measuring the speed of car to see if it is travelling over a limit. It could be times over an hour, a minute, as second or even parts of a second.

This is useful information for Blynk users to know so that we can define apps that do not flood the server.

[DaleSchultz]

I am designing an app wherein a menu selection will cause an update most of the other widgets on the screen and the data for those changes has to come from the hardware side via Blynk.setProperty(); and virtualWrite(); calls.

In other words I expect to send at least 14, probably 23 widget updates at once, and then none for some time. It would look awful and add a lot of complexity if I delayed the screen updates to avoid flooding the server. Usually floods are due to people calling setProperty within a tight loop and usually all the calls are too the same virtual pin, which makes little sense. What I would like to propose is that the flood control shuts off the server when the same virtual pin is called too fast, and let batches of updates pass through OK when they are updating different pins.

For example the limitation could be imposed to something like this:

• No more than n updates per second (measured over 1 second) per pin.
• No more than nn updates to different pins per second (measured over 1 second).

E.g. n = 5 nn = 50

If either condition is exceeded, the server will disconnect.

This would ensure that coding runaways can be shut down, but allows legitimate, SetProperty() and virtualWrite() spikes to occur as needed by the app.

[Gunner]

FYI, as you have been informed and has been referenced many times by @Pavel himself… Ideas and suggestions for future Blynk are now requested and prefered to be sent to the roadmap. This helps keep them in one spot for developer reference and a degree of community voting to assist with judging actual community interest vs a small group or individual’s unique desires.

https://portal.productboard.com/blynk/tabs/2-all-your-ideas

@DaleSchultz

What I would like to propose is that the flood control shuts off the server when the same virtual pin is called too fast, and let batches of updates pass through OK when they are updating different pins.

Meanwhile, you are assuming that the server reacts differently when multiple SAME vPin requests happen as opposed to multiple DIFFERING vPin process occur. I highly doubt that is the case as Blynk’s protocol looks virtually the same for each and every process. Flooding is simply a case of too much too fast, and the needs for the governor are also dictated by the Cloud Server and it’s bandwidth costs as well as IoT infrastructure as compared to Local Server and user’s internal network environments.

If you want faster, ungoverned transfers, use a Local Server and the #define BLYNK_MSG_LIMIT 0 command as listed here

This all said, if you have actual code, library contributions and/or “solutions to issues”, perhaps the proper venue for submitting them is Blynk’s various GitHub repositories instead of creating multiple topics that slowly fade away into the queue.

[DaleSchultz]

and has I have posted before, the ideas submitted via the roadmap cannot be found again.

And no, I am not a Blynk developer and nor are you.

I’ll submit these to the roadmap too but dont expect to find them again.

[Gunner]

@DaleSchultz

the ideas submitted via the roadmap cannot be found again.

I have no solid answer… but I suspect that since the developers have their own ideas and targets, they probably filter out any ideas that they know will never get further action… why waste time otherwise?

Or they are just very busy with Blynk 2.0

Just keep submitting them to the roadmap, and see what sticks.