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

Blob handling #148

Open
amm3 opened this issue Mar 14, 2022 · 4 comments
Open

Blob handling #148

amm3 opened this issue Mar 14, 2022 · 4 comments

Comments

@amm3
Copy link
Contributor

amm3 commented Mar 14, 2022

It appears that the blob_handler() function isn't getting called at certain critical junctures. My understanding was that the core code would call this function (if defined in a plugin) as it processed packets, every time the stream changed direction. It actually looks like the blob_handlers aren't called until the connection closes and the blobs are formed/iterated.

@jpsnyder
Copy link

The blobs are indeed handled after the connection closes.
https://github.com/USArmyResearchLab/Dshell/blob/master/dshell/core.py#L606

I believe it doesn't process them inline because of potential retransmitted packets for an older blob.
https://github.com/USArmyResearchLab/Dshell/blob/master/dshell/core.py#L1208

@dev195
Copy link
Contributor

dev195 commented Mar 16, 2022

I see both sides of this issue. It's useful for the blobs to be complete before processing, which is why Dshell currently handles them when the connection closes. But it is also useful to handle blobs as they come, such as when users interrupt the decoding process or listen live on the wire.

Would there be interest in a command-line switch? Dshell could default to handling blobs after the connection closes, but will handle them immediately if the user sets the flag? There might be issues if packets are retransmitted, but users can accept that risk when they use the flag.

@amm3
Copy link
Contributor Author

amm3 commented Mar 16, 2022

I could see the command-line option being useful, but it seems like something more tied to the design of a particular decoder/plugin. Perhaps the plugin could set its default/desired behavior on instantiation with a command-line option to override that?

@jpsnyder
Copy link

jpsnyder commented May 4, 2023

Unsure how that could be added effectively. It looks like blobs are only calculated once requested by the .blobs property on the Connection object (which probably helps with speed).

Perhaps the Connection object can follow the producer/consumer model like the other elements and have a produce_blobs() function. Which would have the Connection object statefully produce any new blobs since the last time it was called. Although it should be understood that the blob's produced this way would be different than if you did conn.blobs since they are prematurely being passed through the chain.

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

No branches or pull requests

3 participants