Предположим, серверу требуется выдать очередное задание для вычисления. У него всегда есть выбор: запросить клиентскую программу новую порцию данных, либо выдать блок, от узла, который мы считаем выбывшим из вычислений.
В методе произвольной выборки есть три варианта организации хода вычислений:
Получение всех порций данных от прикладной программы, вне зависимости от состояния узлов уже получивших задания и затем передача заданий он узлов, которые мы считаем неактивными.
Получение всех порций данных от прикладной программы, вне зависимости от состояния узлов уже получивших задания и затем последовательная передача заданий он узлов которые дольше всего находятся в состоянии расчета (при этом статус узла не важен).
Решение о передаче некоторой порции данных новому узлу, если мы считаем что предыдущий узел, который рассчитывал эту порцию, неактивен до получения всех порций от прикладной программы.
В последнем варианте при необходимости выдачи нового задания сервер вначале просматривает список уже розданных заданий, и если время ожидания какого-либо из них истекло, выдает его. Если все времена заданий, которые сейчас находятся в обработке, не истекли, то прикладная программа запрашивается об очередном задании.
Время ожидания ответа рассчитывается как расчетное время ожидания ответа умноженное на коэффициент K_wait. Расчетное время ожидания ответа, в свою очередь, определяется исходя из статистики работы с каждым конкретным клиентом и размера текущего задания. Коэффициент K_wait – важный атрибут работы системы: при его увеличении мы ожидаем пакет в течении большего времени и соответственно меньше шанс, что мы пошлем один и тот же пакет двум разным вычислительным узлам (задержка может быть связана как с неточностью предсказания времени расчета, так и с загрузкой вычислительно узла), с другой стороны при увеличении этого коэффициента мы увеличиваем размеры окна, что ведет в прикладной программе к увеличению времени ожидания очередной порции данных, а также увеличение размеров окна требует дополнительных ресурсов памяти центрального сервера.
Ожидание времени расчета вычисляется исходя из размера задания (физический размер памяти, требуемый для текста задания, влияет на скорость передачи его по сети) и сложности задания (она выдается клиентской частью прикладной программы). Сложность задания представляет собой оценку времени его расчета на некотором абстрактном вычислителе, этот параметр выдается прикладной программой вместе с заданием. При невозможности такой оценки, каждому заданию присваивается сложность расчета единица.
6.10 Фоновые процессы на сервере
Параллельно с основными процессами на сервере работают фоновые процессы, которые не влияют на ход вычислений. Работают два основных процесса: проверка состояния узлов и отображение хода вычислений. Проверка состояний узлов – это процесс, периодически проверяющий все узлы из таблицы текущих вычислений, на предмет их активности, при истечении некоторого времени, которые вычисляется аналогично времени ожидания ответа, но с другим коэффициентом – K_wait_dead. K_wait_dead должен быть больше K_wait. Если узел не отвечает больше чем, время ожидания активности, то он помечается в таблице как неактивный.
Второй фоновый процесс – отображение хода вычислений периодически сбрасывает на жесткий диск файл доступный, через Веб-сервер, в этом файле отображается статистическая информация о ходе вычислений (количество активных узлов; количество узлов находящихся в процессе взаимодействия с сервером; суммарная вычислительная мощность системы), а также полная таблица подключенных узлов.
6.11 Проверка корректности результата
При получении сервером результата расчета, в ряде случаев возникает необходимость убедиться в правильности расчетов, это необходимо чтобы избежать умышленного искажения результата, либо искажения результатов расчетов в результате некорректно работающего узла. Есть четыре основных пути проверки корректности:
Отсутствие проверки корректности. Результат вычислений будет передаваться непосредственно в прикладную программу, которая его сохраняет.
Прямой метод проверки корректности, когда проверкой занимается серверная часть прикладной программы. Прикладная программа запрашивается с уровня проверки корректности парой (запрос, результат) и выдает ответ верный результат, либо нет. При неверном результате информация об ошибке сохраняется в специальных логах для дальнейшей разборки, почему это произошло. В штатном режиме функционирования системы ошибок быть не должно, поэтому номер узла выдавшего ошибку сохраняется в черном списке, и соединения от него больше не принимаются.
Прямой метод проверки корректности, когда проверкой занимается другой узел. В этом случае в начало списка заданий попадает задание на проверку, при этом решается обратная задача, где исходными данными служит уже полученный результат вычислений. Результат этого расчета должен совпасть с исходными данными (проверки на идентичность производится в прикладной программе), в противном случае результат считается не полученным и номера узлов занимавшихся проверкой и перепроверкой заносятся в черный список.
Метод перерасчета результата. Ключевым параметром метода перерасчета служит коэффициент перепроверки – вещественное число большее единицы. В случае целого числа этот коэффициент означает скольким узлам надо раздать одно и то же задание. Полученные результаты сверяются друг с другом, и в случае расхождения используется метод голосования для определения правильного результата. Если равное количество узлов проголосовало за каждый вариант результата, проводятся дополнительные проверки для определения победителя. Все узлы, которые выдали неверный результат, заносятся в черный список и в дальнейшем не смогут получать задания на обработку. Если коэффициент перепроверки больше 1 и меньше 2, – то он характеризует вероятность, с которой очередной пакет будет проверен. Эта вероятность составляет коэффициент перепроверки минус единица. В случае вещественного числа большего 2, коэффициент перепроверки аналогично характеризует вероятность проверки пакета ближайшим к нему сверху, либо ближайшим снизу целым числом проверяющих узлов.