Giter Club home page Giter Club logo

lightning-filter-old's Introduction

This is the readme for the Lightning filter prototype

The directory contains the following:

src/

contains the entire source code for the Lighning filter, more specifically all c source files. src/config7 contains the config files, which can be modified, although the format specification must not be changed. src/lib/ contains the necessary dependencies, especially the CMAC assembly implementation and the key_manager.so file. The src directory provides a buildall.sh script and a run.sh script, for more information how to run the code, consult the RUN_INSTRUCTIONS.md file. To build we use make.

#go/ Contain all go source code. More specifically the metrics_exporter and the key_manager. The metrics exporter must be run in addition to the Lighning filter if metrics shall be exported. The key_manager subdirectoy contains a script to compile and move the libarary to the correct location. Nonetheless the src/lib/ should already contain an up-to-date library file.

#testing/ contains the source code files for the unit tests. For unit testing we use cmocka. Due to difficulties with building the units tests are currently integrated into the apllication itself and are always run if the main unit test call is not commented out in the application.c file.

#prometheus_config/ contains a simple config file for prometheus in order to create a job for both the metrics exporter and the Prometheus node exporter

#spirent/ contains the spirent config files that were used during this thesis for evaluation purposes. They can be used as a reference when creating new streamBlocks.

#pcap/ contains a number of pcap files with different SCION packets that can be used to create new streamBlocks in Spirent. The directory contains to scripts to generate new pcap file. However, these scripts are very simple and must be modifed for any specific generator changes.

#Structure and Modifcations The project is an extension of two previous projects, thus there are a few artifacts left in the codebase. There are some, in retrospect, questionable design decisions and the code is not omptimally structured. This is largely a consequence of having multiple authors and last minute design changes.

In general the most important source file is the scionfwd.c source file. For anyone aiming to understand the code or wishing to extend the project, these functions are essential to understand:

scion_filter_main() contains the entire DPDK set-up (port, lcore, memory and queue allocation) scionfwd_main_loop() contains the main processing core loop (data-plane) scionfwd_should_forward() contains the decision logic for the data-plane key_manager_main_init()& key_manager_main_loop() contains the key-manager code dos_init()& dos_main_loop() contains the rate-limiter code

lightning-filter-old's People

Contributors

jgude avatar

Watchers

James Cloos avatar Marc Frei avatar Kamila Součková avatar Juan A. Garcia Pardo avatar Adrian Perrig avatar  avatar Benjamin Rothenberger avatar  avatar  avatar

Forkers

marcfrei

lightning-filter-old's Issues

Documentation of `lightning-filter/go/metrics_exporter/` is unclear

In the lightning-filter/go/metrics_exporter/ the following sentence is present as a prerequisite

Make sure that your local prometheus server is running and that prometheus is configured to listen to port 8080.

However, by reading metrics_exporter.go the following behaviour can be deduced

  • github.com/prometheus/client_golang/prometheus is used in order to expose Prometheus metrics over HTTP
  • port 8080 will be used by the HTTP server

The behaviour of the code is contradictory to the documentation - if an operator starts an arbitrary workload listening on a port 8080, go run metrics_exporter.go will fail binding to the port 8080 because it would have already been grabbed.

Also, by the reference architecture of exposing Prometheus metrics, it must not be required to start any local nor remote Prometheus server. An arbitrary application exposing metrics using HTTP server should expose them under /metrics endpoint without assuming whether any process consumes them. Apart from this, Prometheus uses "pull" model therefore it is a responsibility of the monitoring system to consume (i.e. "pull") metrics from the application exposing them.

I'm guessing what was meant to be written was something like

after executing `go run metrics_exporter.go` the metrics will be available on the `localhost:8080/metrics`".

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.