Difference between Driver and Protocol

[Christofer Dutz <ch...@c-ware.de>]

Hi all,

as the question just came up in the slack channel and I think it could be interesting for more.

“I have question about netty codecs and their implementation - I see there are `driver` and `protocol` modules which do pretty much same thing - provide netty handlers. I am curious where plain udp->bacnet codec should land - in driver or protocol?”

In general the driver should be pretty straight forward an minimal. All it should do, is to setup the pipeline and provide the means for the driver-manager to find the implementation.

The main reason for this split is that we currently have only one type of driver per protocol, but this will change in the future. Here we will be having a serial port version, a tcp version and a passive-mode version.
Each of these have a large set of differing dependencies. So we could build one “driver to support em all” with a very large number of dependencies, or we provide multiple drivers with different communication endpoints. I prefer the later version and that’s why in one of my latest refactoring I introduced this split (after discussing things here, of course 😉 ).

So think of the protocols al pure implementation of the protocols, and the drivers select the protocol implementations they need, assemble the protocol stack and the IO connector (Serial, TCP, Raw Ethernet) and connect everything together. (Looking at the S7 driver it doesn’t just connect one layer with one connector, it’s much more a stack of protocols being assembled).

I hope that explains this little design consideration we did here.

Chris