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

Dispatcher withholds messages due to bundle timetag #110

Open
xioTechnologies opened this issue Oct 21, 2019 · 3 comments
Open

Dispatcher withholds messages due to bundle timetag #110

xioTechnologies opened this issue Oct 21, 2019 · 3 comments

Comments

@xioTechnologies
Copy link

A mismatch between the client and server date/time causes dispatcher will withhold all messages until the application runs out of memory and crashes!

Please add an option to disable this scheduling and instead allow the application to handle the bundle timetags. I suggest a flag named "disable bundle scheduling", or similar. If this flag is set then the dispatcher would:

  • Provide OSC messages as soon as they are received
  • Include the timetag associated with each message
@attwad
Copy link
Owner

attwad commented Oct 27, 2019

Indeed, another alternative could be to have a set of flags to:

  • cap number of messages held in memory (easy, can lead to unexpected behavior)
  • discard messages scheduled too far in the future (easy, can lead to unexpected behavior)
  • have a special dispatch /currenttimestamp method or something alike for the client to verify that its clock is somewhat synchronised with the server (requires client work, only takes care of the synchronisation issue)

@xioTechnologies
Copy link
Author

You seem to be looking past the simplest use case: To just print received OSC.

I expect this is something that almost all users would want to do at some point, even if just for debugging. No buffering, no scheduling, no discarding of messages; just provide the data that was received when it was received.

@attwad
Copy link
Owner

attwad commented Oct 29, 2019

Yup that would also work, the purpose of that library was to be somewhat useful and abstract that away from the clients but offering them a way to get the raw messages/bundles if they want is also fair.

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

No branches or pull requests

2 participants