Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UDP packet capture plugin #195

Open
telegraphic opened this issue Jan 17, 2023 · 2 comments
Open

UDP packet capture plugin #195

telegraphic opened this issue Jan 17, 2023 · 2 comments
Labels

Comments

@telegraphic
Copy link
Collaborator

I've just created a repository on bf-plugins/bf_udpcap that builds the UDP capture code. The hope is to make it easy to add new packet formats.

Still plenty left to do -- so far it compiles into a shared object.

I have opened this issue to use as documentation and for discussion.

@jaycedowell
Copy link
Collaborator

I went to look at that repo today and I'm getting a 404.

@jaycedowell
Copy link
Collaborator

I've been thinking about this the last couple of weeks. A few thoughts:

  • I think plugins are a good idea for packet capture since there will always be some other format people want to use.
  • I also think that making the formats included with stock Bifrost configurable at build time is a good idea because not everyone will want every format. This is kind of what DSPSR does with its backends.default file.
  • I don't think what's in ibverb-support currently is great for plugins. For bf_udpcap-style plugins it's probably ok because you introduce a new set of classes/blocks for each new format. For something like a dynamic plugin system where the modes are exposed through the same class/block there are problems.

On that last point the problem I see is in ibverb-support is with the "callback manager" class. It's easy to drop in a few files to define a new format and compile them but adding the callback requires a change to that manager class. I started trying an idea on ibverb-support-alt but that hasn't yielded anything useful.

There is also the bigger picture question of separate vs dynamic plugins that I'm not sure about. I like the concept of dynamic plugins where there is one class/block that manages everything but that may be harder to achieve. Separate plugins are probably easier to implement but then there are lots of classes/blocks to create. Maybe that isn't so much of an issue since the different file formats that are supported now are different blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants