-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
The blobs are indeed handled after the connection closes. I believe it doesn't process them inline because of potential retransmitted packets for an older blob. |
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. |
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? |
Unsure how that could be added effectively. It looks like blobs are only calculated once requested by the Perhaps the |
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.
The text was updated successfully, but these errors were encountered: