Архитектура системы BOINC

Разработка приложения на систему распределенных вычислений на BOINC. Создание образа виртуального сервера. Архитектура системы BOINC. Описание работы Web-сервера, характеристики его основных служб. Преимущества использования виртуализации в BOINC.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 10.02.2017
Размер файла 1,1 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

BOINC_OPTIONS options;

boinc_options_defaults(options);

options.multi_thread = true; // if your app's main process uses multiple threads

options.multi_process = true; // if your app uses multiple processes

boinc_init_options(&options);

Сделайте это, прежде чем создавать потоки или процессы.

Если же для приложения необходимо использование GPU(Графический процессор), Для инициализации введите следующее:

BOINC_OPTIONS options;

boinc_options_defaults(options);

options.normal_thread_priority = true;

boinc_init_options(&options);

В операционной Windows, в этом случаее, приложение будет запущено в нормальном приоритете потоков, GPU будет работать в полную силу даже если CPU загружена.

Завершение

Когда приложение выполнилось оно должно вызвать:

int boinc_finish(int status);

Не нулевой статус завершения приложения бывает в случае ошибки.

Не вызывайте функцию exit(0), это приведет к перезагрузке приложения.

Если при завершении вы хотите показать сообщение пользователю,используйте:

boinc_finish_message(int status, const char* msg, bool is_notice);

если флаг " is_notice " True, приложение будет показано в приложении-клиен(поддерживается в версиях клиента выше 7.5, в других версия сообщение не будет показано).

Конвертирование имен файлов

Приложения, которые используют сгенерированные входные или выходные файлы, должны вызвать:

int boinc_resolve_filename(char *logical_name, char *physical_name, int len);

или

int boinc_resolve_filename_s(char *logical_name, std::string& physical_name);

для того чтобы сконвертировать физическое имя файла к логическому. К примеру, вместо того чтобы использовать:

f = fopen("my_file", "r");

приложение должно использовать:

string resolved_name;

retval = boinc_resolve_filename_s("my_file", resolved_name);

if (retval) fail("can't resolve filename");

f = boinc_fopen(resolved_name.c_str(), "r");

Не используйте boinc_resolve_filename() для файлов с атрибутом "copy_file", или временными файлами. Это должно использовать для всех файлов описанных в шаблонах, или файлах что являются частью версии приложения.

Оболочка входных/выходных данных

В приложении необходимо использовать, вместо fopen():

boinc_fopen(char* path, char* mode);

Она решает проблемы связанные с платформами, в этом случае

Есть несколько повторных попыток открыть файл, чего нет в fopen().

Контрольные точки

В объемных работах есть необходимость периодически записывать текущее состояние на жесткий диск. Это и называется контрольной точкой. Этот файл должен включать в себя все, необходимые для продолжения работы, данные. При запуске программа читает контрольную точку и начинает с места последнего вычисления.

При проектировании приложения необходимо предусмотреть места где можно сделать контрольную точку.

Для того чтобы приложение могло сделать контрольную точку необходимо вызвать:

int boinc_time_to_checkpoint();

если вернуло не ноль, то приложение должно немедленно сдл\елать контрольную точку. Затем вызовите:

void boinc_checkpoint_completed():

Контрольные точки делаются быстро, по этому, стоит чаще создавать их.

Контрольная точка создается только в том случае, если прошел заданный интервал времени, с момента создания последней контрольной точки.

Выставить интервал можно двумя способами:

Первый, это выставив пользовательские параметры в приложении-клиент.

Второй, можно выставить в ручную в приложении вызвав:

boinc_set_min_checkpoint_period(int nsecs);

Критические секции

void boinc_begin_critical_section();

void boinc_end_critical_section();

Используется в том случае, если вы не хотите чтобы в период выполнения кода заключенного между ними, приложение не было завершено или сброшено пользователем ядра.

Вывод прогресса

BOINC manadger выводит, состояния текущих процессов и их прогресс.

Для того чтобы обновлять статус необходимо вызвать функцию:

boinc_fraction_done(double fraction_done);

значение параметра fraction_done варьируется от 0 до 1, показывая готовность приложения. Эту функцию можно часто вызывать. Значения переменной не должны убывать.

Временная информация

int boinc_wu_cpu_time(double &cpu_time);

Выводит общее затраченное процессором время, на одно задание.

double boinc_elapsed_time();

Выводит затраченное время за последнюю рабочую сессию.

Автономный режим

Для тестового запуска, приложение может быть запущено в "автономном" режиме или же под контролем BOINC клиента. В обоих случаях можно запрограммировать разное поведение приложения, к примеру, с целью вывода отладочной информации.

int boinc_is_standalone(void);

Возвращает не ноль если работает в автономном режиме и ноль если запущено под контролем BOINC клиента.

Замечания по сборке приложений

Кардинальной разницы в сборке приложений для разных операционных систем, нет, есть только некоторые нюансы которые стоит учитывать при написании исходного кода, к примеру, пути файлов в разных системах могут быть написаны по разному. Поэтому каждое приложение лучше собирать на целевой платформе, либо же к примеру для linux, можно собрать приложение на сервере используя скрипт make.

3.6 Исполняемые файлы распределенного приложения

В подкаталоге apps/ каталога проекта находятся файлы приложения, которые будут выполняться на клиент-компьютерах участников проекта. Для этого необходимо создать в каталоге apps/ подкаталог с именем приложения (которое совпадает с именем в фале project.xml: <name>uppercase</name>). В новый каталог надо скопировать исполняемые файлы приложений разработанных для различных платформ, описанных выше.

Имя исполняемого файла должно строго соответствовать следующему формату:

<имя приложения>_<версия>_<платформа>[.<расширение>]

Именно этот формат используется для записи имени в нашем случае:

имя приложения: meapp;

версия: 1.0;

платформа: windows_intelx86;

расширение:.exe;

В каталоге ~/server_stable/apps располагаются исполняемые файлы для платформ и исходные коды приложений uppercase, которые можно использовать и собирать проекты для любой интересующей вас платформы.

Если все исполняемые файлы расположены в указанном месте и были внесены необходимые правки в project.xml, следует занести новую информацию в базу данных.

Для этой цели есть специальная утилита называемая update_version:

boincadm@boincserver:~/projects/meapp>./bin/update_version

Утилита идентифицирует исполняемые файлы и подбирает для них подходящие платформы:

Found <App#1 meapp> version 100 for

<Platform#3 windows_intelx86>: meapp _1.0_ windows_intelx86

Далее предлагается формирование электронной подписи для исполняемых файлов. Заканчивается процесс добавления приложения следующими строками:

Committed:

<AppVersion#1 meapp 100 windows_intelx86>

Touched trigger file to make feeder re-read app_version table from database

Done

Проверить список поддерживаемых платформ можно перейдя по ссылке *server-ip*/apps.php (рисунок 4).

После завершения этапа по созданию проекта. Следующим будет этап создания рабочей единицы (Work Unit) для нашего проекта.

Сначала создаем текстовый документ в каталоге download, файл будет содержать исходные данные для приложения meapp:

boincadm@boincserver:~/projects/ meapp > echo

"Hello BOINC World" > download/in

Теперь нужно создать шаблоны входных и выходных данных в подкаталоге templates.

Рисунок 4. Приложения и поддерживаемые платформы

3.7 Создание рабочих единиц проекта

Шаблоны входных и выходных данных

Различные свойства заданий, таких, как количество и наименование их входных и выходных файлов, описываются парой XML документов, называемых шаблонами ввода и вывода. Обычно те же шаблоны используются нескольких заданий.

Шаблоны входных данных

Файл шаблона ввода описывает входные файлы задания: потребности в ресурсах и параметры планирования.

Он имеет вид:

<input_template>

<file_info>

<number>0</number>

[ <gzip/> ]

[ <sticky/> ]

[ <no_delete/> ]

[ <report_on_rpc/> ]

[ <url>...</url> ]

[ <url>...</url> ]

[ <md5_cksum>...</md5_cksum> ]

[ <nbytes>...</nbytes> ]

</file_info>

[... other files ]

<workunit>

<file_ref>

<file_number>0</file_number>

<open_name>NAME</open_name>

[ <copy_file/> ]

</file_ref>

[... other files ]

[ <command_line>-flags xyz</command_line> ]

[ <rsc_fpops_est>x</rsc_fpops_est> ]

[ <rsc_fpops_bound>x</rsc_fpops_bound> ]

[ <rsc_memory_bound>x</rsc_memory_bound> ]

[ <rsc_disk_bound>x</rsc_disk_bound> ]

[ <delay_bound>x</delay_bound> ]

[ <min_quorum>x</min_quorum> ]

[ <target_nresults>x</target_nresults> ]

[ <max_error_results>x</max_error_results> ]

[ <max_total_results>x</max_total_results> ]

[ <max_success_results>x</max_success_results> ]

[ <size_class>N</size_class> ]

</workunit>

</input_template>" [12]

Элементы и теги должны быть на отдельных строках, как показано.

Каждый <file_info> описывает входной файл:

<number>

Используйте 0, 1,...

<gzip/>

переводит файл в формат gzipp (сжатым), чтобы уменьшить нагрузку на сеть. Вы должны поставить файл с ключом --gzip. Только 7.0+ клиенты могут обращаться с сжатыми файлами; старые клиенты будут скачивать файлы в несжатом виде.

<sticky/>

если он присутствует, файл остается в клиенте после завершения задания.

<no_delete/>

если он присутствует, файл не удаляется с сервера после завершения задания. Используйте это, если файл используется в качестве входных данных для более чем в одной работе.

<report_on_rpc/>

если он присутствует, файл отчета будет в каждом запросе планировщика. Включите это для совместимости со старыми (до 7.x) клиентов; 7.0+ клиенты сообщают какие файлы должны остаться.

Следующие ключи используются для файлов, которые располагаются на сервере (или серверах), которые находятся вне вашего сервера BOINC:

<url>

задает каталог (т.е. он должен заканчиваться /), в котором имя файла будет добавлено, чтобы дать ему URL. Если файл копируется, вы можете поставить больше, чем один.

<md5_cksum>

Проверка контрольной суммы MD5

<nbytes>

Размер файла. <gzipped_nbytes>: если <gzip/> задается, размер файла GZIP.

<File_ref> описывает путь файла, на который ссылается:

<file_number>

0, 1, и т.д.

<open_name>

Логическое имя файла

<copy_file>

Если присутствует, файл копируется в папку “рабочего слота”

Рабочие параметры включают:

<command_line>

Аргументы командной строки, которые передаются в главную программу.

Примечание: если вы используете оболочку BOINC, используйте <append_cmdline_args /> в файле job.xml, чтобы передать аргументы командной строки из обертки (the wrapper) к завернутый приложениям(the wrapped application).

<rsc_fpops_est> и т.д.

Работа имеет атрибуты, такие как объем дискового пространства будет использоваться. BOINC будет поставлять разумные значения по умолчанию для них, но вы должны поставить правильные значения; в противном случае, например, BOINC может попробовать запустить работу на хост с недостаточным дисковым пространством.

<size_class>

Укажите класс на размер задания.

Шаблон ввода (замещенный с именами файлов и URL-адресов) хранятся в поле базы данных с лимитом 64 КБ. Этого достаточно для примерно 200 входных файлов, меньше, если вы используете длинные имена файлов или несколько URL ссылок. Если этого не достаточно, вы можете использовать BOINC сжатие файлов, чтобы поместись несколько файлов в одну ссылку на для скачивания, а также расширение их до запуска на клиентской машине.

Шаблоны вывода

Файл шаблона вывода описывает выходные файлы задания. Оно имеет вид:

<output_template>

<file_info>

<name><OUTFILE_0/></name>

<generated_locally/>

<upload_when_present/>

<max_nbytes>32768</max_nbytes>

<url><UPLOAD_URL/></url>

[ <gzip_when_done/> ]

</file_info>

<result>

<file_ref>

<file_name><OUTFILE_0/></file_name>

<open_name>result.sah</open_name>

[ <copy_file>0|1</copy_file> ]

[ <optional>0|1</optional> ]

[ <no_validate>0|1</no_validate> ]

[ <no_delete/> ]

</file_ref>

[ <report_immediately/> ]

</result>

</output_template>

Элементы и теги должны быть на отдельных строках, как показано на рисунке. Элементы включают в себя:

<file_info>

описывает выходной файл.

<name>

физическое имя файла. Обычно используют <OUTFILE_0>, <OUTFILE_1> и т.д.; BOINC заменит сгенерированным именем на основе имени задания.

<upload_when_present/>

устарел, но вам нужно включить это чтобы работать с старыми версиями клиентов ниже 7.0.

<gzip_when_done/>

использовать это, чтобы сжать выходной файл перед загрузкой,

<file_ref>

Описывает, как как выходной файл будет распознан приложением.

<open_name>

логическое имя, по которому приложение будет ссылаться на файл.

<copy_file/>

если он присутствует, файл будет создан в каталоге слот, и скопировать в каталог проекта, после работы закончен. Используйте это для унаследованных приложений.

<generated_locally/>

всегда включают это для выходных файлов.

<max_nbytes>

Максимальный размер файла. Если фактический размер превышает этот, файл не будет загружен, и работа будет отмечена как ошибка.

<url>

Адрес обработчика загрузки файла. Вы можете вставить это в явном виде, или использовать <UPLOAD_URL />, чтобы использовать URL-адрес в файле config.xml вашего проекта.

<optional>

если 0 или отсутствует, ваше приложение должно создать файл, в противном случае работа будет отмечена как ошибка.

<no_validate>

если это true, не включайте этот файл в процессе проверки (результат относится только если вы используете простой побитовый валидатор).

<no_delete/>

если он присутствует, файл не будет удален на сервере даже после завершения задания.

<report_immediately/>

если он присутствует, клиенты будут сообщать работу сразу же после того как выходные файлы загружены. В противном случае они могут ждать до дня. (Реализовано в 6.12.27+ клиентах только).

Примечание: при его создании, имя его шаблона выходного файла сохраняется в базе данных. Файл читается, когда выходные файлы создаются, которые могут использоваться в течении нескольких дней или недель спустя. Таким образом, редактирование файла шаблона вывода может повлиять на существующие файлы вывода. Если это не желательно, необходимо создать новый файл шаблона вывода.

Вы можете безопасно удалить файл шаблона ввода после создания последнего файла работы с ним. Тем не менее, файлы шаблонов вывода должен существовать до тех пор, пока любая задача, что относится к нему, не будет завершена (т.е. копии больше не будут созданы).

Шаблон вывода, связаны с именами файлов и URL-адресов, хранится в поле базы данных с лимитом 64 КБ. Это накладывает ограничение около 50 выходных файлов; Точное количество зависит от длины ваших файлов и URL-адресов. Если вам нужно больше файлов, вы можете использовать BOINC сжатие файлов, чтобы поместись несколько файлов в одну ссылку на файл для загрузки, до завершения каждой задачи на клиентской машине. После того как вы запустите несколько рабочих мест за счет вашего проекта, вы можете сравнить размер расширенного XML с 65535 предела, выполнив следующую MySQL запрос:

select max(length(xml_doc_in)), max(length(xml_doc_out)) from result;

Теперь все готово к созданию рабочего задания нашего проекта. Запускаем следующую команду:

boincadm@boincserver:~/projects/meapp>./bin/create_work

-appname meapp -wu_name test -wu_template templates/meapp_wu

-result_template templates/meapp_result in

Где:

--appname <название> - название приложения;

--wu_name <название> - название рабочего задания;

--wu_template <имя файла> - локальный путь и имя файла шаблона рабочего задания, принадлежащего проекту. Обычно шаблоны располагается в templates/;

--result_template <имя файла> - локальный путь и имя файла шаблона результата, принадлежащего к проекту.

В утилите create_work имеется множество дополнительных, но необязательных, параметров, узнать о которых можно на странице BONC-wiki.

3.8 Запуск фоновых процессов

Далее следует этап запуска проекта, что представляет собой запуск его фоновых процессов:

boincadm@boincserver:~/projects/meapp/> bin/start

Entering ENABLED mode

Starting daemons

Starting daemon: feeder -d 3

Starting daemon: transitioner -d 3

Starting daemon: file_deleter -d 3

Утилита status выводит какие фоновые процессы запущены и какие файлы используются.

boincadm@boincserver:~/projects/myapp> bin/status

BOINC is ENABLED

Таблица 2. Выходные сообщения команды status

DAEMON

pid

status

lockfile

disabled

commandline

1

40782

running

locked

no

-d 3

2

40810

running

locked

no

transitioner -d 3

3

40787

running

locked

no

file_deleter -d 3

4

44922

running

locked

no

my_work_generator -d 3

5

40792

running

locked

no

sample_bitwise_validator -d 3 --app meapp

6

40795

running

locked

no

sample_assimilator -d 3 --app meapp

Данная утилита, полезна в том случае, если возникли какие то проблемы с проектом, если в какой-то из служб неполадки, существуют log-файлы, они находятся в каталоге log, он расположен в oincadm/projects/test/log_debian7.

4. Программа-клиент BOINC

4.1 Установка программы-клиента BOINC

Дистрибутивы программ-клиента хранятся на странице загрузки официального сайта BOINC, так же для unix и мас систем пакеты включены в списки стандартных репозиториев(в случае с unix, это будут boinc-client, boinc-mаnаger и boinc-gui).

Вне зависимости от способа установки программы-клиента, все основные данные по проектам хранятся в \data\projects\.

Для начала нужно запустить графический менеджер программы(см. рисунок 5)

Рисунок 5. Менеджер проектов BOINC

При первом запуске вам будет предложено подключиться к какому-либо проекту, упрощать этот процесс будет специальный помощник (см. рисунок 6).

На этом шаге предоставляется выбор проекта, к которому вы можете присоединиться, затем можно пройти регистрацию, чтобы начислялись очки за ваш вклад в проект, так же можно присоединится к одной из команд или же создать свою, таким образом образуется неформальное соревнование по сборке кредитов.

Всю информацию по проекту можно получить на сайте проекта.

Рисунок 6. Добавление проекта BOINC

4.2 Подключение к стороннему проекту

В качестве стороннего проекта выберем “SETI (Search for Extraterrestrial Intelligence, Поиск ВнеЗемного Разума) - это научное направление, цель которого - обнаружить разумную жизнь вне Земли. На первом этапе, известном как radio SETI (радио SETI), используются радио телескопы для слежения за узкополосными радиосигналами космоса. Естественные источники таких сигналов не известны, поэтому их обнаружение может дать подтверждение о существовании внеземной технологии.”[10]

Программа-клиент BOINC после регистрации в проекте, начнет загрузку данных, необходимых для выполнения заданий. Необходимо учесть что в различных проектах время затраченное на получение кредитов различное, так же объем затраченного дискового пространства так же может отличаться, но в программе-клиент BOINC есть квотирование объема выделенного объема памяти. Главное окно показывает текущий прогресс задания, затраченное время и сколько времени осталось до завершения (см. рисунок 7).

Рисунок 7. Выполнение задания

Помимо упрощенного вида окна программы-клиента BOINC, есть “полный вид” - нажмите на кнопку “полный вид” в вкладке “вид” (см. рисунок 8).

Данный вид более информативный, можно получить дополнительную информацию о проекте: общую статистику, информацию об использованных компьютером ресурсов и многое другое.

Некоторые настройки специфичны для различных проектов, другие же являются общими и отражаются на работе программы в целом. В полном виде окна программы-клиента менеджера в пункте меню "Дополнительно" - "Настройки клиента", можно изменить множество параметров описанных выше, а так же время и расписание использования компьютера для вычислений. Настройки интуитивно понятны, и не составит труда изменить их так, чтобы клиент работал так как вам необходимо.

Рисунок 8. “Полный вид” окна программы-клиента BOINC

4.3 Подключение к проекту к созданному

Отличий от способа подключения описанного выше нет, но на этапе разработки, для отладки работоспособности созданного проекта необходимо сделать несколько проверок.

Сначала подключаемся к проекту, введя адрес вашего проекта: http://*server-IP*/meapp.

Далее, если все шаги были выполнены верно, предлагается зарегистрироваться на проекте, тем самым вы проверяете работоспособность Веб-интерфейса.

После этого вы должны увидеть сообщение об успешном подключении к проекту (рисунок 9).

Рисунок 9. Результат - успешное подключение к проекту

Далее необходимо перейти в “полный вид”, и открыть “просмотр событий”, в этом окне подробно описываются все этапы работы клиента с проектом:

Подключение к серверу.

Соединиться с планировщиком.

Проверить настройки клиента.

Скачать исполняемый файл и входные данные, соответствующий рабочей клиентской платформе.

Сверить контрольные суммы скаченных файлов.

Выполнить вычисления.

Отправить решение на сервер.

Получить новую порцию заданий.

В случае ошибки какого либо этапа будет выведено сообщение начинающееся с “[error]”, что позволит увидеть проблемы с проектом.

приложение виртуальный сервер boinc

Заключение

Для моей работы я использовал, описанный выше, образ виртуального сервера представленный сайтом разработчика, но в связи с тем что образ необходимо было запустить через программу Hyper-V, потребовалось с конвертировать образ в подходящее расширение. После запуска образа и проведения, описанных выше, подготовительных настроек, был был запущен сервер "92.242.57.37".

После чего был использован скрипт make-project, чтобы получить шаблон приложения для изменения. Перед тем как приступить непосредственно к решению поставленной проблемы, были проведены ряд настроек для работоспособности тестового приложения, после чего можно было подключится к проекту используя ссылку "92.242.57.37/test" В дальнейшем были использованы исходные коды предоставленные разработчиками в качестве примера приложений для системы BOINC,

Поставленная передо мной задача была уже реализована для системы MPI, но первоначальная архитектура данного решения не подходила для системы BOINC, необходимо было адаптировать исходные коды используя шаблон. В связи с этим, мной было принято решение по переводу программы в формат подключаемых библиотек, чтобы, после модификации архитектуры, приложение вызывало входные данные и использовала их в функциях библиотек. После этого необходимо обеспечить функциональность проекта в рамках сервера BOINC, для чего были изменены основные демоны и документы (такие как work_generator, config.xml, шаблоны входных/выходных данных и т.д.).

В конечном итоге приложение работает на сервере и используя стандартный менеджер проектов BOINC, предоставленный на сайте разработчиков, по ссылке "92.242.57.37/test" можно подключится для помощи в вычислениях по поставленной задачи.

Список литературы

1. Folding@home team stats // http://fah-web.stanford.edu/cgi-bin/main.py?qtype=osstats2

2. Cстатистика проектов BOINC // http://boincstats.com/en/stats/5/project/detail

3. Debian вики // https://wiki.debian.org/

4. Официальный российский ресурс распределенных вычислений на платформе BOINC // http://www.boinc.ru

5. Основной официальный сайт системы BOINC // http://boinc.berkeley.edu

6. Русскоязычная документация по Ubuntu //http://help.ubuntu.ru

7. Install a real boinc server on ubuntu (breezy badger) // http://j4cques.blogspot.ru/2005/10/install-real-boinc-server-on-ubuntu.html

8. Главная страница проекта Einstein@Home // http://einstein.phys.uwm.edu/

9. The BOINC server virtual machine // https://boinc.berkeley.edu/trac/wiki/VmServer

10. Главная страница проекта SETI@home // http://setiathome.berkeley.edu/

11. Submitting jobs locally // http://boinc.berkeley.edu/trac/wiki/JobSubmission

12. Setting up a BOINC server // http://boinc.berkeley.edu/trac/wiki/ServerIntro

13. The BOINC application programming interface (API) // http://boinc.berkeley.edu/trac/wiki/BasicApi

Размещено на Allbest.ru


Подобные документы

  • Определение, свойства и характеристики распределенных систем баз данных. Основная задача систем управления ими. Архитектура распределения СУБД. Сравнение технологий файлового сервера и "клиент-сервера". Стратегия распределения данных по узлам сети ЭВМ.

    курсовая работа [601,3 K], добавлен 24.05.2015

  • Обзор существующих объектных архитектур. Архитектура программного обеспечения. Создание веб-сервиса "Библиотека", предоставляющего механизмы работы с данными на стороне клиентского приложения. WEB-сервис и трехуровневая архитектура в основе приложения.

    лабораторная работа [1,5 M], добавлен 16.06.2013

  • Разработка приложений для смартфонов на ОС Android для сети аптек "Фармация". Архитектура операционной системы Android. Архитектура и реализация приложения. Его функциональность. Описание работы мобильного приложения. Расчет затрат на создание продукта.

    дипломная работа [1,6 M], добавлен 17.06.2017

  • Сущность, развитие и применение СОМ-технологий, их достоинства, недостатки, терминология. Особенности СОМ-интерфейса, сервера, клиента, расширений. Локальные и удаленные серверы, их функции и реализация. Технология OMG CORBA и архитектура комплекса.

    курсовая работа [632,7 K], добавлен 13.11.2011

  • Связь между клиентом и сервером, поддерживаемая посредством передачи сообщений. Конфигурация подчиненного и перенаправителей. Архитектура специальной распределенной вычислительной системы, в которой приложение делится на клиентский и серверный процессы.

    контрольная работа [126,8 K], добавлен 08.02.2015

  • Архитектура и функции СУБД. Инфологическая модель данных "Сущность-связь". Ограничения целостности. Характеристика связей и язык моделирования. Манипулирование реляционными данными. Написание сервера на Java.3 и приложения-клиента на ActoinScript 3.0.

    курсовая работа [935,3 K], добавлен 09.07.2013

  • Анализ решений и выбор платформы виртуализации. Обоснование выбора VMwareESXi в качестве платформы для создания учебного класса. Системные требования к аппаратной части для выбранной платформы. Создание макета на основе сервера виртуализации VMwareESXi.

    дипломная работа [4,1 M], добавлен 12.04.2017

  • История и основные сведения о сервере. Классификация и ресурсы серверов. Важность системы охлаждения для сервера. Выбор компонентов для сборки сервера. Основные неисправности и способы их устранения. Проведение технического обслуживания и ремонта сервера.

    дипломная работа [2,1 M], добавлен 24.06.2015

  • Характеристики распределенных систем баз данных, формируемые путем "интеграции" разнородных аппаратных и программных средств. Концепция дифференциального файла для различных приложений. Сравнение разных технологий файлового сервера и "клиент-сервера".

    курсовая работа [411,9 K], добавлен 28.05.2015

  • Организация корпоративного файлового сервера, выполняющего функции прокси-сервера на базе ОС Linux. Процесс его реализации. Выбор оптимальной аппаратно-программной платформы. Расчёт сметы затрат на выполнение объёма работ по созданию FTP-сервера.

    дипломная работа [2,0 M], добавлен 06.07.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.