update ideas & readme
This commit is contained in:
Norwin Roosen
parent
997fbe0d2a
commit
93473eba8f
42
IDEAS.md
42
IDEAS.md
|
|
@ -1,11 +1,16 @@
|
|||
# feature ideas
|
||||
- pluggable cli: commands for image, text, shader rendering
|
||||
- more draw modes
|
||||
- patterns
|
||||
- https://github.com/MarcelMue/konstrukt ?
|
||||
- image scaling
|
||||
- snake
|
||||
- sheep.exe
|
||||
- offset rand: random size/color
|
||||
- proper public api for the fast network handling
|
||||
- `Fluter` abstraction, implementing `Reader` to update commands? ringbuffer?
|
||||
- support animations / frame concept
|
||||
- visualization client
|
||||
- CnC: server distributes jobs to connected clients
|
||||
- or fully P2P using [2D CAN / Z-ordercurve adressing](https://github.com/noerw/geo-dht) (p2p implementation needed)
|
||||
- webassembly port?
|
||||
- use userland tcp stack (e.g. https://github.com/google/netstack or even https://github.com/luigirizzo/netmap)
|
||||
- support (stackable) effects
|
||||
- make job distribution fully P2P using [2D CAN / Z-ordercurve adressing](https://git.nroo.de/norwin/geo-dht)
|
||||
|
||||
# performance considerations
|
||||
- server limitations: rendering is bottleneck. maybe artificial limitations (commands per draw, connections per IP, queue)
|
||||
|
|
@ -13,8 +18,8 @@
|
|||
- sync sending with draw frequency (?)
|
||||
- use virtual subnets for more IPs (ipv6?) (?)
|
||||
- client limitations: PCI bus is bottleneck? depends on HW I guess
|
||||
- precompute everything
|
||||
- distribute across cores for max PCI bus saturation (?)
|
||||
- use userland tcp stack (e.g. https://github.com/google/netstack or even https://github.com/luigirizzo/netmap)
|
||||
- network limitations: packet size, ACKs, congestion
|
||||
- treat benchmarks on `loopback` with care, it has no packet size limitation. real world interfaces will enforce a max size of 1514 bytes [1]
|
||||
- avoid packet split if >1514B (?)
|
||||
|
|
@ -22,25 +27,4 @@
|
|||
- https://stackoverflow.com/questions/5832308/linux-loopback-performance-with-tcp-nodelay-enabled
|
||||
- cognitive limitations: draw order
|
||||
- randomized pixel order should give a better idea of the image with equal dominance (?)
|
||||
|
||||
# concept: CLI for distributed hochwasser v2
|
||||
|
||||
> pixelflut endlich *durchgespielt*
|
||||
|
||||
```
|
||||
hochwasser --server
|
||||
provide [type] [input] --effect --offset --scale --port --nosend
|
||||
subscribe --connections --shuffle --diffmode
|
||||
view --fullscreen
|
||||
```
|
||||
|
||||
- CLI via `github.com/spf13/cobra`
|
||||
- `--server` refers to pixelflut server or hochwasser jobprovider, depending on mode
|
||||
|
||||
- jobprovider has different input types (`image`, `text`, `shader`?), each is parsed into an `image.GIF`
|
||||
- jobprovider also sends image itself?
|
||||
|
||||
- when subscriber connects to jobprovider, `GIF` is split up, and (re)distributed to all subscribers
|
||||
- protocol: (address,offset,imgdata) serialized with `gob`?
|
||||
|
||||
- viewer fetches into framebuffer, renders via opengl?
|
||||
- use an energy function like in seam carving to prioritize regions?
|
||||
|
|
|
|||
31
README.md
31
README.md
|
|
@ -2,13 +2,9 @@
|
|||
<p align="center"><img src="benchmarks/hochwasser_shuffle_vs_ordered.gif"/></p>
|
||||
<p align="center"><img src="benchmarks/nmzs.gif"/></p>
|
||||
|
||||
Highly efficient, distributed [Pixelflut] client.
|
||||
Highly efficient distributed [Pixelflut] client.
|
||||
|
||||
> Hochwasser brings back the */fun/* in social DDoSing!
|
||||
>
|
||||
> No more micro-ddosing: Get Hochwasser now and experience highs never seen before!111!
|
||||
|
||||
- Can send static images, text, generated patterns (animations upcoming)
|
||||
- Sends static images, text, generated patterns (animations upcoming)
|
||||
- REPL enables fast iterations
|
||||
- CnC server + client architecture (it's webscale!) (can also run in a single process)
|
||||
- Faster than [sturmflut] (in some benchmarks at least)
|
||||
|
|
@ -17,11 +13,32 @@ Highly efficient, distributed [Pixelflut] client.
|
|||
[pixelflut]: https://cccgoe.de/wiki/Pixelflut
|
||||
[sturmflut]: https://github.com/TobleMiner/sturmflut
|
||||
|
||||
### testimonials
|
||||
> Pixelflut endlich *durchgespielt*.
|
||||
>
|
||||
> - Steffen Cybert
|
||||
|
||||
> N-no more micro-ddosing: bring on ssome Hochwasser and exppperience colors never seen befffore!1!
|
||||
>
|
||||
> - Morty
|
||||
|
||||
> Hochwasser brings back the D in *social DDoSing*! Man, I forgot which one..
|
||||
>
|
||||
> - Doc Brown
|
||||
|
||||
## build / install
|
||||
1. have a `go` installation >= 1.12
|
||||
2. `go get github.com/SpeckiJ/Hochwasser`
|
||||
3. `go install github.com/SpeckiJ/Hochwasser`
|
||||
|
||||
> The help texts may be lacking, it's recommended to read `rpc/repl.go`.
|
||||
|
||||
## hacking
|
||||
Look at the `github.com/SpeckiJ/Hochwasser/pixelflut` subpackage, it contains the performance sensitive core.
|
||||
|
||||
The code is getting somewhat ~~bloated~~enterprise-ready, so if you want to quickly render a fun thing,
|
||||
it may be easier to just build a separate executable on top of `pixelflut.Flut()`, than to extend Hochwasser.
|
||||
|
||||
## benchmark
|
||||
The following benchmark was run on a max-spec X280 against version [d4c574b].
|
||||
|
||||
|
|
@ -52,6 +69,6 @@ go run main.go -image benchmark/test.png -connections 10
|
|||
[iperf]: https://iperf.fr/
|
||||
|
||||
## future ideas
|
||||
For future ideas check [IDEAS](https://github.com/SpeckiJ/Hochwasser/blob/master/IDEAS.md)
|
||||
see [IDEAS](https://github.com/SpeckiJ/Hochwasser/blob/master/IDEAS.md).
|
||||
|
||||
<p align="center"><img src="benchmarks/hochwasser_vs_sturmflut.gif"/></p>
|
||||
|
|
|
|||
Loading…
Reference in New Issue