Spam scale
Spam Scale
What is a spam scale?
A spam scale [1] is a feature of a hubsoft that restricts users to send messages as often as they want ( or possible bots ). A spam scale usually must allow a certain amount of messages to pass through ( or dispatch them ), in order not to damage hub performance but rather keep a balance between user requirements ( searches, chat messages and so on ) and the amount of messages that the server running the hub software can dispatch in a certain time.
Regular spam scale
A normal linear spam scale has a single parameter, named interval. Hubsofts usually allow this parameter to be set with a granularity of seconds or milliseconds. According to this implementation, each message from the user must come at least after the interval has passed, otherwise the message is dropped.
For example in searches, the interval might be 12 seconds. In this case, if the user sends a search, in the next 12 seconds it cannot send another one. Even if it does, it will be ignored by the hub. After the interval expires the user can search again. The same goes for chat messages.
Advantages
- Very easy to implement
- Low memory usage, easy to maintain hub performance
- Easy to understand and use by hub administrators
Disadvantages
- On large hubs, search interval might grow to even 1000 seconds, which will exponentially grow user frustration and lower the usability of the hub to very low levels
- The human factor will prevent users from using the hub efficiently ( unless they use a script to search at a regular interval )
- Client auto-searches might make an user search impossible ( grab the search before human user can do it )
- Any mistake in the searched string will result in a very long time of wait until next search is possible
Logarithmic spam scale
Implemented in DSHub.
This spam scale is not linear, but logarithmic. This means that each search is done at a different time than the next one. This time we have 3 parameters : log_base, log_max and cooldown.
First search that user attempts is served immediately. Next search after log_base time, next after log_base^2, log_base^3 and so forth until log_max searches have been done. After this limit is reached, user has to wait cooldown time for another burst of searches.
This implementation considers the human factor: people do not search every x seconds, they do some searches now, wait for download, then search for more stuff again. This way, an user gets to have more searches at some amount of time, then it has to wait a considerable amount of time until another burst ( most users just minimize client and wait for their downloads to finish ).
The hub may decide to remember the search and broadcast it to the other users after the timeout is completed ( DSHub does this ), so the user doesn't have to remember when his next search will be available, but just give the command and at a future point in time the hub will reply with results.
The logarithmic search scale also makes a difference between user searches and automatic client searches. Client searches are done by searching TTH and client ones by strings. TTH search can also be done manually but that is quite rare. For the automatic searches there is no point in using logarithmic scale since they are done at a regular interval anyway. This scale is useful only for user searches.
Advantages
- Reduces user frustration, makes the hub more human friendly
- No problem if user typed wrong the search string, even on a very large hub
- Search now, download later
- Protects user searches, handle automagic ones separately
Disadvantages
- More difficult to implement
- More difficult to set by hub administrators
- Hard to find optimal values, more need to be tested.
