Helix icon indicating copy to clipboard operation
Helix copied to clipboard

Support different types of processes lifecycles on TOP

Open renatomassaro opened this issue 7 years ago • 2 comments

Process lifecycles:

  • direct - Process with a clear goal/target/objective, has an ending. The time required for completion is usually shown to the player. Examples: FileTransfer (download/upload), editing a log, overflow/bruteforce attack.

  • recursive - The process runs endlessly. It has a target, but the user doesn't know which one exactly is it. Once the target is deemed processed, the user is notified about it, and the process selects a new target, starting from scratch. If no targets are select, the process runs anyway, and the user does not know that. Examples: LogRecover (system-wide), FileSeeker.

  • daemon - The process runs endlessly. It usually does not have a target. Instead, the process is used as means to 1) enabling some in-game action or 2) increasing/hardening in-game defense against remote attacks. Examples: Firewall (passive).


Current TOP, rewritten at #322, only supports direct. Adding both recursive and daemon should require minimal changes to the allocator, and a new interfarce under Resourceable (in order for recursive protects to select the next target).

Edit: support for recursive process added at #410

renatomassaro avatar Oct 30 '17 00:10 renatomassaro

recursive process type was implemented at #410, refer to LogRecoverProcess for usage example.

Implementation of recursive process is based on the SIGRETARGET signal. When the process objective is reached, the process may perform its side-effect (e.g. pop out a log revision; mark a file/connection as found; etc) and then send the retarget signal.

When SIGRETARGET signal is received, Processable.retarget/2 is called. It's up to each process to define how the next iteration should go, but basically during the retarget step, the process may change any object target(s) and its objectives, effectively creating a new iteration.

Note that, to avoid race conditions, one should issue the SIGRETARGET signal only after the side-effect has been committed (performed).

renatomassaro avatar Aug 16 '18 11:08 renatomassaro

Wo4king on the game but when do we get refunds and replays on the hacker experience 2 discord ur over due on ur 3-5 business days

On Thu, Aug 16, 2018, 06:09 Renato Massaro [email protected] wrote:

recursive process type was implemented at #410 https://github.com/HackerExperience/Helix/pull/410, refer to LogRecoverProcess for usage example.

Implementation of recursive process is based on the SIGRETARGET signal. When the process objective is reached, the process may perform its side-effect (e.g. pop out a log revision; mark a file/connection as found; etc) and then send the retarget signal.

When SIGRETARGET signal is received, Processable.retarget/2 is called. It's up to each process to define how the next iteration should go, but basically during the retarget step, the process may change any object target(s) and its objectives, effectively creating a new iteration.

Note that, to avoid race conditions, one should issue the SIGRETARGET signal only after the side-effect has been committed (performed).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/HackerExperience/Helix/issues/324#issuecomment-413509096, or mute the thread https://github.com/notifications/unsubscribe-auth/ALKQCT8eu7NuSmrWzaEpwMutAZeGLKyPks5uRVMFgaJpZM4QKi3k .

Deathslayer222 avatar Aug 16 '18 15:08 Deathslayer222