skip to content
[readonly]

The blob thread's logic: this member's payloads kept durably, pushes to the copy holders with a window, fetches with failover, image assemblies, and `render`

sh
$ sexc add @ajax/mesh-blobd
  • total 3
  • drwxr-xr-x-../
  • drwxr-xr-x-Oct 27 05:23v/# 1 version
  • drwxr-xr-x-Oct 27 05:23files/# the files of 0.1.0
latest
0.1.0, published Oct 27 05:23 by ajax
owners
ajax
license
MIT
dependencies
@ajax/mesh-check ^0.1.0, @ajax/mesh-strbuf ^0.1.0, @ajax/mesh-omap ^0.1.0, @ajax/mesh-abi-peer-frames ^0.1.0, @ajax/mesh-jobs-id ^0.1.0, @ajax/mesh-jobs-spec ^0.1.0, @ajax/mesh-blobs-store ^0.1.0, @ajax/mesh-blobs-frame ^0.1.0, @ajax/mesh-blobs-durable ^0.1.0, @ajax/mesh-assemble ^0.1.0, @ajax/mesh-ref-sha256d ^0.1.0, @ajax/pathtrace-scene ^0.1.0, @ajax/pathtrace-z ^0.1.0, @ajax/pathtrace-view ^0.1.0, @ajax/pathtrace-default-scene ^0.1.0
dependents
@ajax/mesh-jobd
keywords
mesh alphaos blobs replication pathtrace
homepage
https://github.com/thomasdavis/alpha-c-mesh/tree/main/packages/mesh-blobd
repository
https://github.com/thomasdavis/alpha-c-mesh
==> README.md <==
1# @ajax/mesh-blobd
2
3The blob thread's logic, sans threads: this member's blob store (`@ajax/mesh-blobs-store`), the blob
4frames on the peer links (`@ajax/mesh-blobs-frame`), and the image assemblies
5(`@ajax/mesh-assemble`).
6
7- **Own payloads.** The jobs thread hands over this member's payloads. Each is reserved in the store
8  and written by the writers (`.tmp`, fsync, rename, then one directory fsync per batch). It is kept
9  in memory until its copies are durable, and those bytes are counted so jobd can stop taking leases
10  past `BLOB_MEM_MAX`.
11- **Pushes.** `F_BLOB_PUT` goes through the link's bulk queue, with at most `PUT_WINDOW`
12  unacknowledged per member. `F_BLOB_ACK` comes back once the receiver's copy is durable, or refused
13  when its store is full.
14- **Every copy is a job's.** A push, an own payload or a kept fetch makes that job's reference, even
15  when the same bytes are already here for another job.
16- **Fetches.** These serve the leader's parked results and an assembly's next passes. Each blob is
17  asked of one holder at a time (else any member up), and the next is tried on a refusal, a timeout or
18  a blob that doesn't hash to its name. At most `FETCH_MAX` are in flight.
19- **Assemblies.** These cover the jobs a viewer asked for (`render`), and on the leader every active
20  pathtrace job. Each tile's passes are read here or fetched, and folded in pass order. `render`
21  answers with the status text, a PPM, a BMP, or the raw tiles for mesh-top.
22
23The world is an `mbd_io`: the peer links, jobd, the writers, the clock. `@ajax/mesh-blobd-run` runs
24it as meshd's blob thread.
25
26## Ported from
27
28[alpha-rust-mesh](https://github.com/rsafier/alpha-rust-mesh) (Richard Safier, MIT):
29`crates/mesh-host/src/blobd.rs`: the constants, `JobInfo`, `News`, `Why`, `Fetch`, `Asm`, `Blobd`
30(`keep`, `ensure`, `event`, `ack`, `frame`, `news`, `watch`, `tick`, `render`, `resolve`), `fold`,
31and the writers' batch.
32
33## Differences
34
35- The Rust's fetches are a `HashMap`, so their order is arbitrary. Here they go in hash order.
36- In `render raw` the words are written in host byte order, which is little-endian on every member
37  the mesh runs on.
38
39## Tests
40
41`tests/blobd.c`: three blobd's over a fake network:
42- an own payload kept, counted, pushed once and acknowledged;
43- a full store refusing a push;
44- a fetch from a holder;
45- a corrupt push dropped;
46- a forget removing references, and a push for a forgotten job refused;
47- on-disk writes through the writers;
48- `render` (status, ppm, an unknown job) of an image assembled from a committed result.
49
50## Licence
51
52MIT. See the repository's LICENSE.