Due to IP and MAC addresses being a non-standard type, utils.BinaryRead
was not able to decode them. Move these two types inside utils.go and
teach BinaryRead to use them.
Co-authored-by: lspgn <lspgn@users.noreply.github.com>
* Use write lock when removing template
Since template removal modifies the template set map, it should be done
while holding a write lock, instead of a read lock.
* Optimize BasicTemplateSystem
The BasicTemplateSystem that comes with the library uses a 3-level map
to hold template information to avoid templateId and obsDomainId
collision between multiple protocols and hosts. However, the same can be
done by using a single map with a 64-bit key consisting of version,
templateId and obsDomainId.
This greatly simplifies the code and reduces the number of map lookups
from 3 to 1 per call to GetTemplate.
Co-authored-by: Matheus Castanho <matheus.castanho@dcc.ufmg.br>
The tests are a bit more expansive than the existing tests for sFlow
or NFv5 as we check the whole structure. I am also testing the
String() function as it is easier to read. It is a bit redundant, but
checking only for the wire format makes it difficult to compare with
Wireshark. Only testing for the textual representation is not totally
good as it is not what is used by users of the decode function.
* adds dataframe link decoding
* can map NetFlow/IPFIX fields and bytes sections from sFlow/packets to any field inside the protobuf
* add CLI argument for loading a mapping yaml file
Defer unlocking just after taking a lock when possible (when unlock is
done at the very end) and when not trivial (the function body is more
than a couple of lines). This simplifies a bit some functions (no need
to unlock before each return) and for the other, it may avoid a bug in
the future in case a return is inserted into the body of a function.
Use of defer has been optimized a lot in Go and it is believed that
simpler defers have zero overhead since Go 1.14:
https://golang.org/doc/go1.14#runtime
> This release improves the performance of most uses of defer to incur
> almost zero overhead compared to calling the deferred function
> directly. As a result, defer can now be used in performance-critical
> code without overhead concerns.
