Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
feat: Makes the use of a component socket optional. #147
I worry that the experience of using ice4j without the merging socket with these changes may have lots of "gotchas" (and perhaps the jvb diff illustrates that? I need to take another pass). Most of these (dumb?) questions will probably be answered as I go through the jvb diff, but to help my memory:
- How will the user of the ice4j lib know which specific candidate to use directly (I think there's an event/notification of successful candidates, is that right? Will the user of the lib need to manually read from all successful candidates?)
- When a current candidate fails (and therefore the user needs to start using a different one) is there another event/notification? How will the user of the lib know which next candidate to start using?
- Will the transitions between candidates (e.g. when one fails) result in the loss of any packets? (not necessarily on the network, but packets maybe left in ice4j buffers)
I totally get these changes as something quick to re-run some tests, but if we find that we need to stick with this solution, do you think it's worth reconsidering ice4j a bit to find a better way to integrate this? Or do you think this is as good as it's going to get without significant effort?
1: Without the "component socket" it falls back to the previous ice4j API and behavior. That is, one candidate pair is selected and nominated, and once this is done (we move to the COMPLETED state) you can not change to another pair. You can access the selected pair through
2 & 3: This is not supported. ICE needs to run again.
I'll do the API changes that Ingo suggested which should also fix the tests.