rtpmidid
rtpmidid copied to clipboard
davidmoreno
Retry
UDP is not reliable, not even on ethernet (please see also the MSG_CONFIRM pull-request) so retry everything.
I like the strings in a list idea, but not the change on behaviour.
The first failed at connection so does not create the alsa port, the second on fail will leave the alsa port dangling.
The current behaviour is that if there is a CK timeout it will remove the client, which will close connections and so on. Or so is the theory, I suspect there may be something here. But anyway it should remove the client.
What about keeping CK the same but only retrying regular timeout?
On Fri, Aug 20, 2021 at 10:22 AM David Moreno Montero < @.***> wrote:
I like the strings in a list idea, but not the change on behaviour.
The first failed at connection so does not create the alsa port, the second on fail will leave the alsa port dangling.
The current behaviour is that if there is a CK timeout it will remove the client, which will close connections and so on. Or so is the theory, I suspect there may be something here. But anyway it should remove the client.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/davidmoreno/rtpmidid/pull/72#issuecomment-902524129, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUN5IW3RYM2RZPTNA77ZXXTT5YGEDANCNFSM5CPS5DTA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
The problem is, you can't expect a UDP packet to reach its destiny. A switch' buffers may be full, the peer may be too busy, electronic glitches, tons of reasons. So I think a few retries should be done before giving up.
Code would not apply on current master.
Please open a issue or another pull request.
Thanks a lot anyway for the effort for creating this pull request.