https://old.zeek.org/development/howtos/dpd.html

On June 30, 2020 at 13:32:57, Christofer Dutz (christofer.d...@c-ware.de)
wrote:

Just had another idea ...

How about giving this driver no real transport at all (think we have the
dummy transport ... that works like a charm) and then to provide the means
in the subscription addresses? This way I could start discovering serial,
passive and active ... and perhaps even multiple instances with just one
connection ...

Chris



Am 30.06.20, 19:09 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>:

Hi folks,

for the past weeks I have been thinking about how we could approach the
“discovery” topic.

I think I just had an idea and would like some feedback from you.

So I was thinking about how we could model such a discovery API. In general
it would look pretty different to the existing APIs … at least I thought.

The Idea I just had, was:
How about we create a new “discovery” driver? This can use both the serial
transport as well as the passive-mode transport or even tcp transport for
protocols that allow active discovery mechanisms.

So you would simply create a “connection” to something like
“discovery:raw//eh1” or “discovery:serial:///dev/ttyS0” … now this driver
would be a little special. It would internally query the list of drivers
available on the given system, the same way the DriverManager does it. But
it would check each driver if it implements an interface
“SupportsDiscovery” (or whatever name we give it) … So it would then
initialize an instance of all drivers supporting discovery.

So in the end the DiscoveryDriver would simply try to feed each packet to
each of the drivers and have them check if they can make sense out of that.
If they do, they would start emitting events just the same way a resource
subscription does. (Of course we should probably apply some filtering
mechanism to avoid too much overload)

So a client wanting to use discovery, would use the normal PLC4X API to
connect and then would simply subscribe to the datastream produced by that.

So in the end we wouldn’t be changing anything with the user-facing API and
all could be done internally … and the cool thing we would get all the
integrations working with this without modifications for free :-) … so you
could start simply streaming the discovery data to StreamPipes or Kafka or
log it in IoTDB for intrusion detection or other crazy stuff

What do you think? I have to admit I am currently absolutely happy with
this idea … so please … bombs away … tear it apart ;-)

Chris

Reply via email to