docs.go

// Velociraptor flows are similar to GRR's flows but are optimized for
// speed:

// 1. Velociraptor flows are run directly on the frontend - there is
//    no secondary queuing to a worker like in GRR. This means that
//    flows need to be efficient and ideally simply store their
//    results in the database.

// 2. GRR flows are a state machine, where each CallClient() request
//    may solicit multiple responses. GRR queues these responses
//    before calling the state method so they are delivered to the
//    flow in order. This is inefficient and requires a lot of
//    processing on the front ends. In contrast Velociraptor flows are
//    not state machines - they receive the response to each request
//    as soon as it arrives (without waiting for a status
//    message). Therefore responses may be processed out of order:

// Consider a request issued to the client will generate 2
// responses. The client may send response 1 in one POST operation and
// response 2 in another POST operation.

// Server sends:
//  - request id 1

// Client Post 1:
//  - request id 1, respone id 1

// Client Post 2:
//  - respone id 1, respone id 2
//  - respone id 1, respone id 3, status OK.

// Velociraptor will a actually run the handler three times - for each
// response and for the status.

// GRR flows maintain state while processing each response. The server
// will load the state from the database and prepare it for the worker
// to process. In contrast, Velociraptor does not maintain state
// between invocations. If the flow needs to keep state, they should
// mainain that themselves.

// GRR was designed to allow flows to be long lived, process long
// request/response sequences. In Velociraptor, the focus has shifted
// to make flows very simple and maintain little state. Generally
// flows simply issue client requests and receive their responses to
// store in the database.

package flows