Confirmed users
1,927
edits
Auto-tools/Projects/Pulse/PulseGuardian: Difference between revisions
Jump to navigation
Jump to search
Auto-tools/Projects/Pulse/PulseGuardian (view source)
Revision as of 02:09, 15 April 2014
, 15 April 2014→Design and Approach
(Created page with "= Team = * mcote, dkl, ahmed = Problem = We use RabbitMQ as a pub/sub service which currently allows anyone to subscribe to any queue via a common user account. Some clien...") |
|||
| Line 18: | Line 18: | ||
= Design and Approach = | = Design and Approach = | ||
PulseGuardian will need to know who owns a given queue in order to attempt to contact its owner. There are two good choices: the queue name and the username. The former is simple to set up, since it is entirely defined by the client. We could just use a convention, such as appname_email, where "appname" can be anything, and "email" should be a valid email address. However, since pulse is a public resource, this is open to abuse; anyone could provide anyone else's email, potentially deluging them with pulse messages. | |||
A more secure way is to provide email validation. Thus we will need a simple web client that performs standard registration: accepts a username and password, emails a verification link/code, and creates the user in RabbitMQ when verified. It should also provide a method to reset a user's password and to delete the user. Finally, it should provide a method (REST API) to download archived messages (see below). | |||
The second part is a process that polls RabbitMQ, looking for queues above a set length (WARN_QUEUE_SIZE). If the queue belongs to a user with a properly formatted username (i.e. an email address), a warning email is sent containing the queue name and current queue length. After a second threshold is reached (DEL_QUEUE_SIZE), the queue is deleted, and another email is sent. If the username is not a proper email address (e.g. the public user), the queue is silently deleted when DEL_QUEUE_SIZE is reached (no action is performed at WARN_QUEUE_SIZE). | |||
Interaction with RabbitMQ should probably be via the management plugin's REST API. | |||
We can also, optionally, add a threshold between WARN_QUEUE_SIZE and DEL_QUEUE_SIZE, call it ARCHIVE_QUEUE_SIZE, at which point PeerGuardian will start to consume messages from the queue and archive them to disk. This is advantageous because RabbitMQ keeps all queues in memory, so one rogue queue can eventually take down RabbitMQ. If the queue size falls below ARCHIVE_QUEUE_SIZE, presumably due to the client application resuming, no new messages will be archived unless ARCHIVE_QUEUE_SIZE is exceeded again. When MAX_ARCHIVE_SIZE messages are archived, messages are no longer consumed by PeerGuardian and thus, unless archived messages are consumed by the client, the queue will continue to grow until DEL_QUEUE_SIZE is hit and the queue deleted, as above. | |||
We'll have to think through this feature a bit to determine the implications of a client trying to consume while PeerGuardian is also consuming them (or trying to). | |||
= Implementation = | = Implementation = | ||