update ideas & readme

This commit is contained in:
Norwin Roosen 2021-01-01 14:55:29 +01:00
parent 997fbe0d2a
commit 93473eba8f
No known key found for this signature in database
GPG Key ID: 24BC059DE24C43A3
2 changed files with 37 additions and 36 deletions

View File

@ -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?

View File

@ -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>