Bruteforce response as HEBorn currently expects

[chrisfls]

This is the response "format" we're expecting:

type*
access
  # for a full process
    origin_id :: Server.ID
    priority 1~5
    usage
      cpu :: [Percentage :: Float, Absolute :: String]
      mem
      down
      up
    connection_id :: Maybe Connection.ID
  # for a partial
    origin_id :: Maybe Server.ID
    connection_id :: Maybe Connection.ID
state*
file
  id :: Maybe File.ID
  version :: Maybe Float
  name :: String
status[1]
progress
network_id
target_ip
process_id

• [1] Use status to informa a failure reason.

[renatomassaro]

Progress

Progress.Percentage is Maybe too, since recursive/infinite progress do not have neither "Percentage" nor "CompletionDate".

Or, better yet, Progress is Maybe. Just Progress always has both Percentage and CompletionDate.

A good UI component would be to let the user know for how long that process has been running. This one would always exist, regardless of the process type. In order to avoid updating the model every second, it should be a CreationDate (timestamp). I'll add this field to my response.

This means we have two options:

type alias Progress =
{ Maybe Percentage, Maybe CompletionDate, CreationDate }

or

type alias Process =
...
Maybe Progress
CreationDate
...

Pick one, it makes no difference to me. I believe the first one is more intuitive, as all progress-related information is grouped together.

Status

What exactly is this use case? Failed process do not exist on the backend, they are immediately deleted. You'll get "status" notification (details about the failure reason) through events, like BruteforceFailed or FileDownloadFailed.

Process-specific metadata

Some processes have custom metadata. For instance, LogForge process usually have target_log_id as meta data. Where should I put this one? Do note that the content of process metadata may vary according to the context (full process may have additional metadata, partial processes may hide some metadata).

Currently, I'm adding it to a data field, which is a map with custom values for each process. A process without metadata will have an empty map inside data.

[renatomassaro]

%{
  owned: 
    [
      %{
        access: 
           %{
             connection_id: nil,
             origin_id: "10::d0f4:a550:c13c:3257:2288", 
             priority: 3,
             usage: %{cpu: [0, 0], dlk: [0, 0], ram: [0, 0], ulk: [0, 0]}
            },
       data: %{
         target_log_id: "30::ec5d:5ab4:b517:75eb:6e7b"
       }, 
       file: %{},
       network_id: "::", 
       process_id: "21::8829:90ba:1852:d2b2:8e8",
       progress: %{
         completion_date: nil, 
         creation_date: 1506587596,
         percentage: 0.5
       },
       state: "running", 
       target_ip: "73.65.171.246",
       type: "log_forger"
    },
   %{access: %{connection_id: "0:1:1:8f9b:d52e:793f:72a:eb7b",
       origin_id: "10::d0f4:a550:c13c:3257:2288", priority: 3,
       usage: %{cpu: [0, 0], dlk: [0, 0], ram: [0, 0], ulk: [0, 0]}}, data: %{},
     file: %{id: "20::1b20:73e6:536a:b1f:bb65", name: "Unknown file",
       version: nil}, network_id: "::",
     process_id: "21::6872:26bc:6e1a:12fd:c694",
     progress: %{completion_date: nil, creation_date: 1506587596,
       percentage: 0.5}, state: "running", target_ip: "64.233.100.235",
     type: "cracker_bruteforce"}],
  targeting: [%{access: %{connection_id: nil}, data: %{}, file: %{},
     network_id: "::", process_id: "21::41e3:dc37:2e23:e49f:284e",
     progress: %{completion_date: nil, creation_date: 1506587596,
       percentage: 0.5}, state: "running", target_ip: "73.65.171.246",
     type: "cracker_bruteforce"}]}

(Apparently I'm too tired to indent correctly)

---

Note I've changed the resource_usage format to be

usage: %{
  cpu: %{
    percentage: float,
    absolute: int
  }
}

If you can add a decoder for this, it would be great. It makes my types a lot more consistent

[chrisfls]

Just a note:

Splitting owned and targeting processes is useless (for now). The access field is removing the ambiguity here, so no need for these two lists (unless,of course, you want to change the format to take advantage of that).

Another thing:

We must talk about the effects of not keeping closed processes, we must do some assumptions for UI, because resync requests may remove the process from the client.

[chrisfls]

I'm proposing a change: origin_id => origin_ip