Possible idea towards "multi-connection" drivers

[chrisdutz]

In the past we have sort of hand-built multiplexing layers for Drivers using multiple communication channels. In some drivers, where the paralel channel was logically quite separate from the rest, we simply hand implemented a udp helper, completely avoiding Netty and our driver framework.

Both approaches have the disadvantage of not being very reuseabe also do they make it hard to use our testing framework.

So I thought of the following idea:

• We generally have drivers support multiple channels
• Each channel gets a name (in the default case it could just be named "default")
• Our framework manages the creation of individual channels and setting up their netty pipelines
• The context allows accessing the other channels
• The test-framework is extended to support an additional channel name (and it defaults to "default" if none is provided)

This way we wouldn't need any demultiplexing at the root of the pipeline (some protocols have very differing packet structures)
and we could continue using our test-framework the same way we have been till now.