search

eclipse-agail / agile-core

Source code repository for agile core components
Eclipse Public License 2.0
7 stars 16 forks source link

Possible to DDOS get component Data #21

Closed brettdaman closed 8 years ago

brettdaman commented 8 years ago

I'm building a service that polls the device components on a regular interval. During this I was looking on how realtime I could make the connection so I increased the polling frequency. With 2 devices with one component (so 2 calls at the same time) I can get an update rate of 500ms

If I increase to 100ms It works for a short time until I get ERROR i.a.h.exception.AgileExceptionMapper - Error occured org.freedesktop.dbus.exceptions.DBusExecutionException: The maximum number of pending replies per connection has been reached

That is Expected, what isn't expected is that it will continue until I only receive errors (no more success calls)

ERROR i.a.h.exception.AgileExceptionMapper - Error occured org.freedesktop.DBus$Error$NoReply: No reply within specified time

It would be better if I still received some updates and the rest would be dropped.

Or even better that the gateway would be smart enough to limit the polling to the device and returns a cached version if the frequency is to high.

cskiraly commented 8 years ago

Polling the device is supposed to be a blocking call. Did you wait for the return?

I think we can handle caching in the Device implementation. If we get a request for another Read while one is still being processed, we don't call the protocol, but wait for the previos to finish and return the same value.

brettdaman commented 8 years ago

Please try to call for component value 10 times/second and you will see the pi doesn't respond to anything.

cskiraly commented 8 years ago

We have added a check for ongoing read on a component. If there is an ongoing read while get is called again, the second (third, etc.) get will return the same value, without querying the protocol. This should solve the problem you have seen. We also added a caching on top of this, to avoid reads which would anyway not make sense because of the update period of the underlying sensor.