Java RMI, выбор лидера, алгоритм проверки
Для проекта меня попросили разработать асинхронный распределенный алгоритм Leader-Election (Afek и Gafni). Я должен быть в состоянии растянуть число узлов выбора, насколько это возможно, без нарушения алгоритма. Теперь я разработал код для запуска этого на одной машине, и все, кажется, работает нормально.
Я решил позволить узлам этого алгоритма отправлять сообщения таким образом, чтобы они возвращались только после завершения запрошенного узла (возможно, запрошенные узлы игнорируют запрос, потому что он уступает или не может быть выбран). Этот выбор гарантирует, что мне не нужно создавать зацикленные спящие потоки, которые каким-то образом поглощают вычислительную мощность (я создал потоки, но я только вызываю run, чтобы позволить им запускаться неблокирующим образом по отношению к другим процессам. В них не выполняется цикл while.)
Мои вопросы связаны с проверкой алгоритма (дайте мне знать, если мне нужно разделить их).
Как мне проверить, работает ли алгоритм? Я думал об отправке сообщений регистрации в основной процесс RMI. Стоит ли сравнивать метки времени и заказывать список сообщений? Могу ли я считать системные временные метки причинно-следственными и синхронизированными на нескольких машинах или мне нужно выполнить более начальную синхронизацию?
Как я могу проверить, не сломался ли алгоритм? Конечно, когда Java начинает бросать исключения. Алгоритм утверждает, что количество сообщений увеличивается логарифмически с
так что я не понимаю, как это могло сломаться.
Может кто-нибудь сказать мне, если мой выбор не вернуть контроль сразу после отправки сообщения (через заглушку RMI) вызовет проблемы? Кажется, что это тип рекурсии, и поэтому его гораздо проще реализовать и сложнее отладить.
Как указывалось ранее, я с удовольствием разделю эти вопросы, если их ответ будет несостоятельным друг с другом, а пока я считаю их тесно связанными.