When using UFTP, sometimes a client calls send_abort(group, "Error joining multicast group") - which I do not understand the cause of.
When this happens the server (which is in the announce phase) will set that clients destinfo_t::status to DEST_ABORT.
After this, the sever does not have a case to handle this client when it responds to a later announce.
Is there some setting that I can use on the client or server side to either resolve this or diagnose this further?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
When using UFTP, sometimes a client calls send_abort(group, "Error joining multicast group") - which I do not understand the cause of.
When this happens the server (which is in the announce phase) will set that clients destinfo_t::status to DEST_ABORT.
After this, the sever does not have a case to handle this client when it responds to a later announce.
Is there some setting that I can use on the client or server side to either resolve this or diagnose this further?
Thanks.
The client should be printing a message stating why it can't join the multicast group. Take a look at that to figure out what do to next.
Unfortunately, the log got rolled over and I don't have the prior file.
Perhaps you might also consider throttling the logging, in this case my log begins;
2019/11/25 09:06:41.100985: Switch to new log complete
2019/11/25 09:06:41.100985: [A23623A0/00:0]: Expected REG_CONF, got FILESEG
2019/11/25 09:06:41.100985: [A23623A0/00:0]: Expected REG_CONF, got FILESEG
2019/11/25 09:06:41.100985: [A23623A0/00:0]: Expected REG_CONF, got FILESEG
... (71,000 repeats later)
2019/11/25 09:13:11.441013: [A23623A0/00:0]: REGISTER sent
2019/11/25 09:13:14.122641: [A23623A0/00:0]: REGISTER sent
Locally I will throttle the logging and see how that helps.
Sorry - the bit following the 71,000 repeats was snipped incorrectly, but the 71,000 bit was correct