Bradley Farias

@prdn are we tied to the special worker approach, would a PR for allowing normal workers to act as part of a reduce be fine?

This would be completely transparent to the worker. It would require that the broker be able to multiplex receiving multiple streams from different workers. To the worker there would be...

as a side note we are faking this in a similar way to do multiplexed responses from a worker and sending back [Server Sent Events](http://en.wikipedia.org/wiki/Server-sent_events); just would be using this...

in my scenario the client uses 1 connection and the broker makes multiple connections. The client is demultiplexing a single stream into multiple replies sent from that single connection to...

we can do it client multiplexed first, but then we will need to expose what the worker ids are, which is fine.

@leonpegg what about dns discovery, UDP broadcasts don't work on most public cloud infrastructure.

+1 to separate composable discovery module

@ljharb fixed up, can move the proto to be the `module.exports` value if desired, but using named property access is still up in the air, using `.default` is the future...

@ljharb with potential change to `_interopRequireWildcard`, going to change recommendation to just use `_interopRequireWildcard` rather than a custom interop boilerplate

I bring this up because, whew boy are we in enough of the weeds due to incompatibilities of existing CJS interop w/ babel and ESM