dayorbyte / dispatchd Goto Github PK

Before it's feasible for other people to take part in the project it needs to have build and test infrastructure set up

In order to implement this the server needs to be broken up such that a connection can be associated with an instance of Server after selecting a virtual host

Leaving them out of the initial implementation since they're optional

HTTP/2 is a framed binary protocol, so it makes a lot of sense to allow queue operations via it. The easiest way to do this is probably grpc, so that should be the first option looked at.

Right now the plain auth user/password are ignored. The server should be able to be configured to have users and passwords which are allowed to connect

@jeffjenkins
what is the license usage of this repo. Can you add a license to this .

At a minimum amqp port, admin port, and the directory to write database files to

Use basic.flow and rabbit's connection.blocked extension to stop overactive producers from overloading the server

The router should be able to connect to an upstream AMQP server and forward messages back and forth. It should understand the protocol well enough that it can make intelligent decisions about where to send requests.

In particular, it would be great to be able to declare a queue as being on all downstream hosts and then to publish/consume messages evenly between them. The server would need to look at the client properties and exchange/queue/binding declaration properties to decide where the commands should go

We should batch writes for efficiency. Each write is a stand alone boltdb transaction right now which has to be more expensive than doing everything at once,

After #6 is resolved and we aren't blocking on persistent writes we should short-circuit and not write anything to disk which has been acked or (if auto-acking) fully sent over the network. With an appropriate coalescing system we might never write to disk when acking is off and the system is not backlogged

It should be possible to connect securely using TLS

Would be cool to see this feature.

The server should have a config option to specify a memory limit and if the go process goes over that limit it should panic. Future changes can add better strategies for dealing with the problem, but without a limit they can't be implemented