Skip to content
A scalable and fault resilient HTTP Broadcaster
Go Dockerfile
Branch: master
Clone or download
jderusse Merge pull request #24 from jderusse/fix-reco2
Agent does not re-connect
Latest commit 76f906b Jan 27, 2020
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github/workflows Siwthc from goverall to shogo82148 Jan 10, 2020
docs Replace /hub with /.well-known/mercure Nov 21, 2019
examples Replace /hub with /.well-known/mercure Nov 21, 2019
pkg Handle hub disconnect Jan 27, 2020
.gitignore Initial commit Sep 15, 2019
.golangci.yml Switch golint to golangci-lint Oct 7, 2019
.goreleaser.yml Initial commit Sep 15, 2019
CONTRIBUTING.md Fix CS Nov 21, 2019
Dockerfile Revamp the documentation Oct 7, 2019
LICENSE Revamp the documentation Oct 7, 2019
README.md Fix typos Oct 18, 2019
go.mod Handle hub disconnect Jan 27, 2020
go.sum Handle hub disconnect Jan 27, 2020
main.go Fix CS Oct 14, 2019

README.md

HTTP Broadcast

A scalable and fault resilient HTTP Broadcaster built on top of mercure able to forward an HTTP request to several servers without the need to maintain a registry.

This project has been initialized in order to invalidate a cluster of docker varnish servers.

Description

Each HTTP request sent to a listening http-broadcast is pushed into a mercure HUB, then dispatched to all listening http-broadcast who'll replay the same request.

Schema

Use cases

Example of usage: Send PURGE/BAN requests to a cluster of Varnish containers.

The solution will be to embed a http-broadcast binary alongside each Varnish instance (One could use the Inter-container network communication provided by Kubernetes Pods). By sending a single request to one varnish container, the http-broadcast will take care to dispatch the same request to all varnish instances.

Benefits

  • No need to maintain an index: each server is allowed to start and die without to be registered somewhere
  • Fault tolerant: if a server is temporary unreachable (network issue for instance), messages won't be lost: all missed messages will be re-played once recovered.
  • Scalable: dealing with 1 or 2 000 servers is transparent for the client, it has a single request to perform.
  • Network secured: Servers don't have to be exposed to the client which is complex to set up when the servers are located in different region of the world.

Documentation

Contributing

See CONTRIBUTING.md.

You can’t perform that action at this time.