\chapter{Заключение} В ходе проделанной работы была достигнута поставленная цель и выполнены следующие задачи: \begin{enumerate} \item Исследованы модели использования RPC в олимпиадной системе BACS, выделены предъявляемые к RPC требования в рамках каждой модели; \item исследованы существующие технологии RPC, сделаны выводы о том, что для синхронных RPC с ограниченным временем работы запроса следует использовать gRPC, а для асинхронных RPC без ограничений на время обработки запроса обоснована необходимость создания собственной реализации; \item разработан асинхронный протокол RPC на основе системы очередей сообщений RabbitMQ; \item протокол реализован для языков программирования Go, Python и C\#, представлена оценка эффективности протокола на основе эксперимента. \end{enumerate} На основе реализованного RPC могут создаваться надёжные и масштабируемые распределённые системы. % vim: spell spelllang=ru \begin{titlepage} \thispagestyle{empty} \begin{center} \large МИНОБРНАУКИ РОССИИ\\* Федеральное государственное бюджетное образовательное\\* учреждение высшего образования\\* «Ижевский государственный технический университет имени~М.~Т.~Калашникова» \vspace{1cm} \end{center} \hfill \begin{minipage}{0.3\textwidth} К защите\\* Руководитель направления\\* д.т.н., профессор Лялин В.Е.\\* <<\_\_\_>> \_\_\_\_\_\_\_\_\_ \text{\myyear} г. \end{minipage} \vspace{6em} \begin{center} \textbf{\myfullname}\\* \vspace{1em} \titletext \end{center} \begin{center} \myspeciality \vspace{1em} \textbf{\titletype} \end{center} \vspace{\fill} \hfill \begin{minipage}{0.3\textwidth} \mylabel\\* \myname \vspace{1em} \myteacherlabel\\* \myteacherdegree\\* \myteacher \vspace{1em} Руководитель программы\\* д.т.н., профессор Лялин В.Е. \vspace{1em} \end{minipage} \begin{center} Ижевск \myyear \end{center} \end{titlepage} \setcounter{page}{2} \pagestyle{plain} % vim: spell spelllang=ru \begin{thebibliography}{9} \bibitem{distributed} Таненбаум Э. С. Распределенные системы. Принципы и парадигмы / Эндрю Таненбаум, М. ван Стеен − СПб. : Питер, 2003. − 880 с. \bibitem{rabbitmq} RabbitMQ - Messaging that just works [Online] // RabbitMQ - Messaging that just works. URL: https://www.rabbitmq.com/ \bibitem{grpc} grpc / grpc.io [Online] // grpc / grpc.io. URL: http://www.grpc.io/ \bibitem{compnets} Таненбаум Э. С. Компьютерные сети / Таненбаум Э. С., Уэзеролл Д. − СПб. : Питер, 2016. − 960 с. \bibitem{ejudge} Ejudge [Сайт]. 2006. URL: http://ejudge.ru/ (Дата обращения: 16.06.2014). \bibitem{acmserver} ACM Server [Сайт].2008. URL: http://acm-server.ru/ (Дата обращения: 16.04.2016). \bibitem{bacs2} Bacs 2.0 2006. [Сайт] URL: http://bacs.cs.istu.ru/ (Дата обращения: 16.04.2016). \bibitem{xmlrpc} XMLRPC 2011, [Сайт] URL: http://xmlrpc.scripting.com/default.html (Дата обращения: 16.04.2016). \bibitem{acmicpc} ACM ICPC 2014, [Сайт] URL: http://icpc.baylor.edu/ (Дата обращения: 16.04.2016). \bibitem{interactiveproblem} Мирзаянов М. Р. Интерактивные задачи: алгоритм тестирования, [Сайт] URL: http://codeforces.ru/blog/entry/5152 (Дата обращения: 16.06.2014). \bibitem{linuxns} Michael Kerrisk. Namespaces in operation. 2014 [Сайт] URL: http://lwn.net/Articles/531114/ (Дата обращения: 16.04.2016). \bibitem{linuxcgroups} Paul Menage. CGROUPS 2004. [Сайт] URL: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt (Дата обращения: 16.04.2016). \bibitem{base64rfc} The Base16, Base32, and Base64 Data Encodings. [Сайт] URL : https://tools.ietf.org/html/rfc4648 (Дата обращения: 16.04.2016). \bibitem{activemq} PYTHON MESSAGING: ACTIVEMQ AND RABBITMQ. [Сайт] URL: http://sensatic.net/activemq/python-messaging-activemq-and-rabbitmq.html (Дата обращения: 16.04.2016). \bibitem{amqp} Advanced Message Queuing Protocol. [Сайт] URL: http://www.amqp.org/ (Дата обращения: 16.04.2016). \bibitem{mqcomparison} Evaluating persistent, replicated message queues. [Сайт] https://softwaremill.com/mqperf/ (Дата обращения: 16.04.2016). \bibitem{bunsanpm} Distributed package manager. [Сайт] URL: github.com/bunsanorg/pm/ (Дата обращения: 16.04.2016). \bibitem{streadwayamqp} Go client for AMQP 0.9.1. [Сайт] URL: https://github.com/streadway/amqp (Дата обращения: 16.04.2016). \bibitem{golangprotobuf} Go support for Google's protocol buffers. [Сайт] URL: https://github.com/golang/protobuf (Дата обращения: 16.04.2016). \bibitem{pika} Introduction to Pika. [Сайт] URL: https://pika.readthedocs.io/en/0.10.0/ (Дата обращения: 16.04.2016). \bibitem{protobuf} Protocol Buffers - Google's data interchange format. [Сайт] URL: https://github.com/google/protobuf (Дата обращения: 16.04.2016). \bibitem{rabbitmqdotnet} RabbitMQ .NET client. [Сайт] URL: https://github.com/rabbitmq/rabbitmq-dotnet-client (Дата обращения: 16.04.2016). \bibitem{protobufnet} Protocol Buffers library for idiomatic .NET. [Сайт] URL: https://github.com/mgravell/protobuf-net (Дата обращения: 16.04.2016). \end{thebibliography} \newcommand{\titletype}{ Диссертация на соискание академической степени магистра } \newcommand{\titletext}{ Модели RPC в проектировании олимпиадного сервера } %\newcommand{\myvariant}{16} \newcommand{\mygroup}{M04-191-1} \newcommand{\myname}{Филиппов А.Н.} \newcommand{\myfullname}{Филиппов Алексей Николаевич} \newcommand{\myspeciality}{09.04.04 – Программная инженерия\\* 09.04.04-1 – Разработка программно-информационных систем\\* } \newcommand{\myyear}{2016} \newcommand{\mymonth}{мая} \newcommand{\mydate}{25} \newcommand{\myteacher}{Тарасов В.Г.} \newcommand{\myteacherdegree}{к.т.н., профессор} \newcommand{\myteacherlabel}{Научный руководитель} \newcommand{\mylabel}{Магистрант} \newcommand{\myverifier}{Соболева В.П.} \newcommand{\mydepartmenthead}{Архипов И.О.} \newcommand{\mydepartmentheadlabel}{Зав. кафедрой ПО} \newcommand{\mydepartmentheaddegree}{к.т.н., доцент} % vim: spell spelllang=ru \chapter*{Введение} \addcontentsline{toc}{chapter}{Введение} Разработка систем автоматизации образовательных процессов является важным этапом информатизации общества. Это позволяет повысить эффективность образовательного процесса путём снижения нагрузки на сотрудников, исключения ошибок и неточностей, допускаемых человеком. Также это позволяет создавать программы удалённого обучения без непосредственного участия преподавателя. Автоматизация в сфере образования затрагивает множество аспектов, от электронных табелей успеваемости и расписаний занятий до автоматизированных тестирований учащихся. Неотъемлемой частью образовательного процесса является практическая работа. Она характеризуется решением определённого класса задач в пределах изучаемого курса. Существуют группы задач, решения для которых могут быть проверены в автоматическом режиме, к примеру из курсов программной инженерии. Существуют системы, автоматизирующие проверку решений для таких задач, а также проведения лабораторных и практических работ, соревнований и олимпиад. С ростом количества пользователей таких систем возрастают и системные требования. Одним из способов решения проблем производительности является распределение нагрузки между отдельными серверами проверяющей системы. Это позволяет добиться горизонтальной масштабируемости, то есть возможности увеличения мощности системы путём увеличения количества узлов сети. Такая система уже будет являться распределённой \cite{distributed}. Для них характерно распределение функций и ресурсов между множеством узлов. Такие системы часто реализуют избыточность ресурсов, что позволяет им оставаться работоспособными даже при выходе части узлов из строя. Одной из проблем, которые необходимо решить при создании такой системы, это координация работы узлов системы и передача результатов вычислений между ними. Для решения этой проблемы может применяться концепция RPC -- remote procedure call. Эта концепция позволяет организовать процесс передачи данных в виде запрос-ответ. Различные типы запросов и передаваемых данных создают необходимость использования различных технологий RPC. \textbf{Целью работы} является анализ различных моделей использования RPC и разработка технологии RPC, которая требуется олимпиадной системе, но не имеет аналогов, удовлетворяющих требованиям. Для достижения цели необходимо решить следующие \textbf{задачи}: \begin{itemize} \item исследование моделей использования RPC в олимпиадной системе BACS, а также требований, предъявляемых к RPC в рамках каждой модели; % привязать к предметной области. требования из предметной области \item исследование существующих технологий RPC и анализ их соответствия полученным моделям; \item разработка протокола RPC для олимпиадной системы; \item реализация протокола для языков программирования Go, Python и C\#. \end{itemize} % часть задач должна быть привязана к предметной области % описание моделей посредством кругов эйлера, как характеристики \textbf{Объектом исследования} являются распределённые системы. \textbf{Предметом исследования} являются межпроцессные взаимодействия в распределённых системах посредством RPC. \textbf{На защиту выносятся} результаты разработки и исследования моделей RPC, а также результаты практической реализации технологии RPC. \textbf{Научная новизна} работы состоит в разработке моделей RPC. Представленные в диссертации модели описывают качественные особенности и требования, предъявляемые к RPC. Это вносит ясность в работу инженера при выборе определённой технологии, предоставляя понятный для него алгоритм действий. \textbf{Практическая ценность работы}. На базе полученных моделей разработана технология RPC, которая позволяет организовать асинхронную и надёжную передачу данных с учётом распределения нагрузки и горизонтальной масштабируемости. Данная технология может быть использована для организации вычислений ряда распределённых систем, в том числе BACS, рассмотренной в диссертации. \textbf{Реализация и внедрение результатов работы}. Разработанная технология внедрена в систему проведения соревнований по спортивному программированию BACS, разрабатываемую силами студентов ИжГТУ, и является одним из средств обеспечения отказоустойчивости и масштабирования системы. %\textbf{Апробация работы.} Результаты работы были представлены на международной %научно-практической конференции "Молодежь и наука: реальность и будущее". \textbf{Публикации.} В ходе работы над диссертацией было подано 2 патентные заявки: \begin{itemize} \item Библиотека программных функций для поддержки сетевого взаимодействия между программами в системе <>. Принята 10.12.2015. \item Программный модуль тестирования корректности работы интернет-сайта системы <>. Принята 18.05.2016. \end{itemize} \textbf{Объём и структура диссертационной работы.} Диссертация содержит введение, 3 главы и заключение, изложенные на 103 с. машинописного текста, а также 1 приложения. В работу включены 7 рис., список литературы из 23 наименований. В приложении представлены основные фрагменты исходного кода реализации разработанного RPC протокола. анализ межпроцессных взаимодействий в олимпиадной системе BACS, обзор существующих реализаций, анализ требований и постановка цели и задач работы \textbf{В первой главе} анализируются межпроцессные взаимодействия, делается вывод о целесообразности применения RPC. Делается обзор существующих реализаций RPC. Обосновывается выбор gRPC в качестве синхронного RPC для запросов с ограниченным временем работы, обосновывается необходимость создания асинхронного RPC для запросов с неограниченным временем работы. Формулируются цели и задачи работы. \textbf{Во второй главе} подробно рассматриваются связи между удалёнными компонентами олимпиадной системы BACS и требования к ним. Разрабатывается протокол асинхронного RPC на основе системы очередей сообщений. \textbf{В третьей главе} рассматривается процесс разработки RPC на основе брокера сообщений RabbitMQ. Оценивается производительность реализованного RPC. \textbf{В заключении} диссертационной работы сформулированы основные выводы и результаты выполненных исследований и намечены возможные перспективные направления их развития. \textbf{В приложении} представлены фрагменты исходного кода реализации протокола для языков Go, Python и C\#. % vim: spell spelllang=ru \input head \input config \begin{document} \include{title} \include{referat} \tableofcontents \pagebreak \input introduction \input analysis \input rpcmodel \input development \input conclusion \input bibliography \input appendix \end{document} \input head \input config \begin{document} \include{seletkovtitle} \input introduction \input bibliography \end{document} \begin{frame} \newcommand{\mytitlefont}{\fontsize{12pt}{7.2}\selectfont} \begin{center} \mytitlefont МИНОБРНАУКИ РОССИИ\\* Федеральное государственное бюджетное образовательное\\* учреждение высшего образования\\* «Ижевский государственный технический университет имени~М.~Т.~Калашникова»\\* Факультет «Информатика и вычислительная техника» \end{center} \mytitlefont \begin{center} \mytitlefont \myfullname\\* \titletext\\* \titletype\\* \end{center} \myspeciality \begin{flushleft} \mytitlefont \mylabel \hfill \myname\\* \vspace{1.5em} \ifdefmacro{\myteacherdegree}{ \myteacherlabel\\* \myteacherdegree \hfill \myteacher\\* }{ \myteacherlabel \hfill \myteacher\\* } \end{flushleft} \vspace{\fill} \begin{center} \mytitlefont Ижевск \myyear \end{center} \end{frame} % vim: spell spelllang=ru \chapter{Аналитический обзор межпроцессных взаимодействий и формирование требований к ним} Целью данной главы является анализ межпроцессных взаимодействий в олимпиадной системе BACS, обзор существующих реализаций, анализ требований и постановка цели и задач работы. \section{Олимпиадная система BACS} Олимпиадная система BACS это распределённая система проведения соревнований и лабораторных работ среди учащихся по дисциплинам, связанным с программированием. Система состоит из нескольких компонент, связанных между собой. В олимпиадной системе можно выделить два типа связей: \begin{itemize} \item Запрос существующих данных, пример запросов между Web-интерфейсом и архивом задач приведён на рисунке~\ref{fig:bacsbasicrpc}. При штатной работе системы обработка запроса занимает строго ограниченное время. В случае сбоя запрос может зависнуть. Необходимо прекращать обработку данного запроса, информируя вызывающую сторону об ошибке. Такие запросы являются синхронными. \item Запрос на совершение ресурсоёмкой операции. Такие запросы происходят между Web-интерфейсом и сервером тестирования решений: тестирование пользовательского решения. Длительность тестирования решения заранее неизвестна, потому следует обеспечить надёжность асинхронной обработки запроса. При этом ответ Web-интерфейсу отправляется сервером тестирования самостоятельно. \end{itemize} \begin{figure}[H] \centering \input rs/bacsbasicrpc.dot \caption{Связи между компонентами BACS} \label{fig:bacsbasicrpc} \end{figure} Такие связи являются примером межпроцессного взаимодействия. \section{Межпроцессное взаимодействие} Межпроцессное взаимодействие IPC (inter-process communication) -- это обмен данными между отдельными процессами. Процессы могут быть запущены как в одном адресном пространстве, так и на удалённых компьютерах. Обеспечиваются такие взаимодействия как посредством ядра операционной системы, так и при помощи механизмов пользовательского пространства (к примеру внешних программных модулей). Среди механизмов IPC выделяют механизмы обмена сообщениями, синхронизации, разделения памяти и удалённых вызовов (RPC -- remote procedure call). Для распределённых систем актуальны механизмы, независимые от ядра операционной системы и позволяющие реализовывать связь между узлами, запущенными под управлением различных операционных систем. К таким относятся механизмы обмена сообщениями и удалённых вызовов. \subsection{Обмен сообщениями} Обмен сообщениями -- это форма связи, используемая в параллельных вычислениях, реализуемая путём посылки пакетов информации получателям, которые могут содержать команды и уведомления, а также данные для обработки. Обычно обмен сообщениями реализуется асинхронно, сообщение может быть доставлено неопределённому кругу получателей, в том числе независимо от отправителя, если используется программа-посредник -- брокер. Наличие брокера с одной стороны приводит к централизации системы, с другой позволяет упростить архитектуру. Брокер хранит сообщения до момента доставки, уведомляет об ошибках, реализует маршрутизацию сообщений. \subsection{RPC} Удалённый вызов процедур -- это класс технологий, позволяющих производить вызов процедур одной компьютерной программы из адресного пространства другой. Как правило реализации RPC позволяют абстрагироваться от деталей сетевого взаимодействия, фактически стирая разницу между вызовом удалённой и локальной процедуры. Технологии RPC удобно применять для организации вычислений в распределённых системах. В языках программирования высокого уровня команда есть вызов процедуры. В распределённых системах таким образом команда есть удалённый вызов процедуры. RPC позволяет передавать структурированные данные небольшого объёма (десятки мегабайт). Так как используются типы данных языков программирования высокого уровня, происходит прозрачная интеграция различных частей системы. Любая технология RPC состоит из двух частей: протокола RPC и реализации протокола для конкретных языков программирования. Следует обратить внимание, что для большинства языков программирования следует создавать отдельную реализацию (в некоторых случаях обёртку к существующей), так как в каждом языке есть свои характерные особенности стиля работы, что позволяет сделать реализацию максимально приближенной к языку и понятной пользователям. Протокол RPC с другой стороны является общим, он един для всех реализаций. Это позволяет объединять различные узлы распределённой системы, реализованные на различных языках программирования. Протокол RPC обычно является двухуровневым. Уровень представления данных определяет методы кодирования информации, такие как байтовое представление чисел и других простых типов данных, массивов, строк, структур. Транспортный уровень определяет механизмы передачи уже закодированных байт по сети. Часто используется какой-либо существующий протокол в качестве транспортного. \section{Требования к технологии RPC} Среди требований, предъявляемых к RPC, выделяют: \begin{itemize} \item переносимость данных; \item надёжность; \item производительность; \item персистентность; \item диагностика неисправностей. \end{itemize} \subsection{Переносимость данных} Разные части системы могут быть запущенны на различных платформах. Это включает в себя как различные архитектуры процессора, операционные системы, так и языки программирования и интерпретаторы. Представление данных на различных платформах может существенно отличаться, к примеру, различным порядком байт, выравниванием, размером указателя, представлением строк и массивов. Простое копирование представления данных из оперативной памяти не позволит взаимодействовать различающимся частям системы. Необходим механизм сериализации в платформо-независимое представление для последующей передачи в другую часть системы. Для системы BACS этот критерий является обязательным, так как одним из основных качеств системы является модульность. Это означает заменяемость компонент без изменения интерфейса, а значит возможность замены к примеру языка программирования в отдельных компонентах. \subsection{Надёжность и производительность} Отдельные компоненты могут быть запущены на различных серверах. Сбои при работе сети, технические работы на сервере (даже кратковременные), моменты пиковой нагрузки с временным отказом от обработки новых запросов, – всё это может приводить к недоступности или медленной работе отдельных узлов системы. При запросах к этим узлам остальные узлы должны адекватно реагировать на их недоступность, корректно определяя это в приемлемое время, повторяя запрос при необходимости. \subsection{Персистентность} В асинхронных связях данные являются более ценными, чем в синхронных. Это связано со стоимостью их получения: обработка асинхронного запроса может занимать существенно больше времени, потому желательно избегать повторения запросов без крайней на то необходимости. Эта проблема решается при помощи персистентного хранения запросов и ответов, что даёт возможность получения ответа на запрос, даже если обработчик уже прекратил свою работу, или отправки запроса при отсутствии свободных обработчиков. Ни одна из рассмотренных RPC технологий не реализует это требование. Для его реализации необходим промежуточный сервис -- брокер. \subsection{Диагностика неисправностей} При обработке запросов могут возникать ошибки. Важно как можно более полно передавать информацию об этих ошибках для последующей диагностики системными администраторами или разработчиками системы. В информацию об ошибке может входить стек вызовов, время вызова, данные запроса, идентификаторы вызывающей и принимающей сторон. \section{Обзор существующих технологий RPC} \subsection{XML-RPC} Использует XML для представления данных, HTTP в качестве транспортного протокола. \noindent Пример запроса: \begin{verbatim} examples.getStateName 41 \end{verbatim} \noindent Пример ответа: \begin{verbatim} South Dakota \end{verbatim} Сильными сторонами технологии являются исключительная простота и распространённость среди языков программирования. Недостатками являются низкая производительность и избыточность представления данных (недостаток XML). Последнее влечёт за собой чрезмерную нагрузку на сеть при значительных объёмах передаваемых данных. В случае же если преобладают бинарные данные, они кодируются в base64, специальной кодировке для представления бинарных данных в текстовом виде. Особенностью данной кодировки является увеличение размера передаваемой информации на 33\%~\cite{base64rfc}. \subsection{JSON-RPC} Технология аналогична XML-RPC, за исключением использования JSON вместо XML. Удобна для реализации в Web ввиду распространённости поддержки JSON в браузерах. Сильные и слабые стороны те же. \subsection{D-BUS} Система для организации RPC в пределах одной операционной системы. Оперирует концепцией сервиса: каждое серверное приложение при запуске регистрирует сервис с заранее известным именем. Клиенты будут обращаться к сервису при помощи данного имени. Сообщения в D-Bus бывают четырёх видов: вызовы методов, результаты вызовов методов, сигналы (широковещательные сообщения) и ошибки. Используется собственный бинарный протокол представления данных. В качестве транспортного протокола используется как правило доменный сокет UNIX, но может быть применён и TCP. Сильными сторонами являются высокая скорость работы и широкая поддержка в языках программирования. Так как технология ориентирована на работу в пределах одного компьютера, для распределённых систем не подходит. \subsection{Java RMI} Java remote method invocation -- программный интерфейс вызова удалённых методов в языке Java. \begin{verbatim} import java.rmi.Remote; import java.rmi.RemoteException; public interface RmiServerIntf extends Remote { public String getMessage() throws RemoteException; } \end{verbatim} Для кодирования данных используется встроенная в язык технология сериализации. В качестве транспортного протокола используется TCP с реализованным поверх него собственным бинарным протоколом. Сильными сторонами являются высокая скорость работы и бесшовная интеграция с кодом на языке Java. Недостатком -- поддержка только платформы Java. Последнее не позволяет создавать по-настоящему кросс-платформенные интерфейсы в распределённых приложениях, если только для разработки не используется исключительно Java. \subsection{SOAP} Simple Object Access Protocol -- простой протокол доступа к объектам. Является расширением XML-RPC. Он является более гибким, но также добавляет и свои недостатки к XML-RPC: существуют несовместимые реализации протокола. Технология, как и XML-RPC, снижает скорость работы за счёт передачи данных в форме XML. \subsection{Apache Thrift} Это язык описания интерфейсов для определения и создания служб на различных языках программирования. Является фреймворком RPC. Содержит генератор кода для таких языков как C\#, C++, Cappuccino, Cocoa, Delphi, Erlang, Go, Haskell, Java, OCaml, Perl, PHP, Python, Ruby и Smalltalk. Поддерживает множество форматов передачи и кодирования данных, среди них бинарные и текстовые, в том числе отладочный (легко читаемый человеком), JSON. Поддерживает различные транспортные протоколы, в том числе сетевые. Сильными сторонами являются гибкость, распространённость реализаций для различных языков программирования и совместимость между ними, высокая скорость работы. Основным недостатком выделяют низкое качество документации. Кроме этого технология сериализации данных неотделима от фреймворка, потому её использование для сохранения данных например на жёсткий диск может быть затруднительно. Технология широко применяется компанией Facebook для построения распределённых систем. \subsection{gRPC} gRPC -- высокопроизводительный фреймворк для построения сервисов и клиентов. Разрабатывается компанией Google, находится в открытом доступе. Технология использует Google Protocol Buffers в качестве технологии представления данных. Эта технология широко распространена среди различных языков программирования. В качестве протокола передачи данных используется HTTP/2 -- современная версия протокола HTTP. Она отличается поддержкой параллельной передачи данных в рамках одного соединения. gRPC имеет реализации для C, C++, Java, Go, Node.js, Python, Ruby, Objective-C, PHP и C\#. Отличается высокой скоростью работы и совместимостью между реализациями. К недостаткам относят сложность анализа закодированных данных. Также следует иметь ввиду что в настоящее время многие реализации являются новыми и не получили достаточной стабильности работы. \section{Постановка цели и задач работы} Среди рассмотренных технологий RPC лучше всего удовлетворяют требованиям синхронных связей олимпиадной системы gRPC и Apache Thrift. Обе технологии имеют реализацию для большинства популярных платформ и языков программирования. Предпочтение отдано gRPC по причине лучшей модульности: возможность использовать одинаковый формат данных для хранения и передачи. gRPC использует Google Protocol Buffers, который удобно применять при сохранении данных на жёсткий диск. Существует второй тип связи -- асинхронный. Для асинхронной связи важна персистентность, то есть возможность продолжить обработку сообщения даже в случае временной недоступности отправителя или получателя. Эта возможность обычно реализуется при помощи промежуточного сервера -- брокера сообщений. Ни одна из рассмотренных технологий не удовлетворяет требованию персистентности, таким образом необходимо разработать данную технологию. Разработка ведётся в два этапа: \begin{enumerate} \item разработка протокола, независимого от платформы (операционной системы или языка программирования); \item разработка клиентов для различных платформ, для олимпиадной системы BACS важны Go, Python и C\#. \end{enumerate} \section{Выводы} В олимпиадной системе BACS есть различные виды связей между удалёнными компонентами. Для реализации синхронных связей применимы существующие технологии, выбор остановлен на gRPC. В случае же с асинхронной связью показано, что нет подходящей реализации RPC, потому ставится задача разработки асинхронной технологии RPC на основе брокера сообщений. % vim: spell spelllang=ru \documentclass[xetex,mathserif,serif,10pt]{beamer} %\documentclass[11pt]{article} \usepackage{xltxtra} \usepackage{polyglossia} \setdefaultlanguage[spelling=modern]{russian} %\setmainfont[Mapping=tex-text]{DejaVu Sans} %\setmainfont[Mapping=tex-text]{Liberation Sans} \setmonofont[Mapping=tex-text]{DejaVu Sans Mono} \setmainfont[Mapping=tex-text]{Linux Libertine O} %\setmonofont[Mapping=tex-text]{Liberation Mono} \input dot2tex \usepackage{verbatim} \usepackage{tabularx} \usepackage{float} \usepackage{url} \usepackage{textpos} \usepackage{hyperref} \usepackage{indentfirst} \usepackage{algorithm} \usepackage{algorithmic} \usepackage{graphicx} \usepackage{dirtree} \usepackage{listings} \lstset{ % language=C++, % the language of the code basicstyle=\ttfamily\footnotesize,% the size of the fonts that are used for the code numbers=left, % where to put the line-numbers numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers stepnumber=2, % the step between two line-numbers. If it's 1, each line % will be numbered numbersep=5pt, % how far the line-numbers are from the code %backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} showspaces=false, % show spaces adding particular underscores showstringspaces=false, % underline spaces within strings showtabs=false, % show tabs within strings adding particular underscores frame=single, % adds a frame around the code tabsize=2, % sets default tabsize to 2 spaces captionpos=b, % sets the caption-position to bottom breaklines=true, % sets automatic line breaking breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace %title=\lstname, % show the filename of files included with \lstinputlisting; % also try caption instead of title escapeinside={\%*}{*)}, % if you want to add a comment within your code morekeywords={*,...} % if you want to add more keywords to the set } %\setbeamertemplate{caption}[numbered] \setbeamertemplate{footline}[frame number] \input config %\usetheme{Warsaw} \usetheme{Singapore} \newenvironment{sframe}[2]{\section{#1}\begin{frame}[label=#2]{#1}}{\end{frame}} \begin{document} \title[RPC]{\titletext} \author[Филиппов]{А.~Филиппов\inst{1}} \institute { \inst{1} Ижевский государственный технический университет имени М.Т.~Калашникова } \input beamertitle.tex \begin{sframe}{Цель работы}{target} \begin{block}{Цель} Анализ и разработка технологии RPC для олимпиадной системы. \end{block} \begin{block}{Требования} \begin{itemize} \item Асинхронность \item Надёжность передачи данных \item Переносимость \item Производительность \item Персистентность \end{itemize} \end{block} \end{sframe} \begin{sframe}{Задачи работы}{problems} \begin{itemize} \item \hyperlink{analysis}{Исследование моделей использования RPC в олимпиадной системе BACS, а также требований, предъявляемых к RPC в рамках каждой модели}; \item \hyperlink{review}{исследование существующих технологий RPC и анализ их соответствия полученным моделям;} \item \hyperlink{protodev}{разработка протокола RPC для олимпиадной системы;} \item \hyperlink{binddev}{реализация протокола для языков программирования Go, Python и C\#.} \end{itemize} \end{sframe} \begin{sframe}{Исследование моделей использования RPC}{analysis} \begin{itemize} \item Асинхронность \item Персистентность \item Переносимость \item Производительность \end{itemize} \begin{figure} \centering \resizebox*{!}{0.6\textheight}{\input rs/bacsbasicrpc.dot} \end{figure} \end{sframe} \begin{sframe}{Исследование технологий RPC}{review} \begin{center} \resizebox{\columnwidth}{!}{\begin{tabular}{|c|c|c|c|c|} \hline & Асинхронность & Персистентность & Переносимость & Производительность \\ \hline XML-RPC & + & - & + & низкая \\ \hline JSON-RPC & + & - & + & низкая \\ \hline D-BUS & + & - & - & высокая \\ \hline Java RMI & + & - & - & высокая \\ \hline SOAP & + & - & + & низкая \\ \hline Apache Thrift & + & - & + & высокая \\ \hline gRPC & + & - & + & высокая \\ \hline \end{tabular}} \end{center} \end{sframe} \begin{sframe}{Разработка протокола}{protodev} \begin{figure} \centering \resizebox{\columnwidth}{!}{\input rs/brokerproto.dot} \end{figure} \end{sframe} \begin{sframe}{Реализация протокола}{binddev} \begin{block}{Языки} \begin{itemize} \item Go: github.com/streadway/amqp \item Python: python-pika \item C\#: RabbitMQ.Client \end{itemize} \end{block} \begin{block}{Отправитель} \begin{itemize} \item Подключение и мониторинг соединения с брокером \item Уведомления пользователя о результатах и промежуточных состояниях \end{itemize} \end{block} \begin{block}{Получатель} \begin{itemize} \item Асинхронная отправка промежуточных состояний \item Последовательная обработка заданий \end{itemize} \end{block} \end{sframe} \begin{frame}{Устройство библиотек} \begin{figure} \centering \resizebox*{!}{0.7\textheight}{ \includegraphics[width=\columnwidth]{rs/libbroker}} \end{figure} \end{frame} \begin{frame}{Результаты} $\mu = \frac{\sum_{i=1}^N t_i}{N} = 1.975$ секунд \\* $\sigma = \sqrt{\frac{\sum_{i=1}^N \left(t_i - \mu\right)^2}{N}} = 0.229$ секунд \\* \begin{figure} \centering \resizebox*{!}{0.6\textheight}{ \includegraphics[width=\columnwidth]{rs/performance}} \end{figure} \end{frame} \begin{frame}{Заключение} \begin{enumerate} \item Обзор моделей и требований; \item анализ существующих технологий, необходимость новой технологии; \item разработка протокола RPC на основе очередей сообщений; \item реализация протокола на языках Go, Python и C\#. \end{enumerate} \end{frame} \begin{frame} \Large\centering Спасибо за внимание! \end{frame} \begin{frame}{Содержание} \tableofcontents \end{frame} \end{document} % vim: spell spelllang=ru %\usepackage[x11names,rgb]{xcolor} %\usepackage[utf8]{inputenc} \usepackage{tikz} \usetikzlibrary{snakes,arrows,shapes} \usepackage{amsmath} \chapter{Разработка RPC на основе брокера сообщений} В данной главе рассматривается процесс разработки RPC на основе брокера сообщений RabbitMQ. Оценивается производительность реализованного RPC. \section{Реализация RPC} \subsection{Общая архитектура} При реализации RPC для конкретных платформ важно придерживаться стиля программирования, принятого в рамках самой платформы. Тем не менее можно выделить ряд особенностей, связанных с брокером. Важным достоинством протокола AMQP~\cite{amqp} является его популярность, и как следствие, существует существенное количество его реализаций. В работе представлена реализация протокола RPC для трёх платформ Go, Python и C\#, но в случае реализации протокола для других платформ с императивными языками программирования рекомендуется придерживаться аналогичной архитектуры. За основу реализации берётся существующая библиотека AMQP, а также библиотека Google Protocol Buffers. Используя эти две библиотеки строится логика работы с подключениями к брокеру, обработка и пересылка сообщений, см. рисунок~\ref{fig:libbrokercomponents}. \begin{figure}[H] \centering \includegraphics[width=\columnwidth]{rs/libbrokercomponents} \caption{Устройство библиотек} \label{fig:libbrokercomponents} \end{figure} \begin{figure}[H] \centering \includegraphics[width=\columnwidth]{rs/libbroker} \caption{Устройство библиотек} \label{fig:libbroker} \end{figure} При разработке библиотек выделяется общий компонент -- менеджер подключения. Он отвечает за установку и восстановление соединения с брокером. Такая прослойка позволяет упростить логику работы вышестоящих объектов, На основе менеджера подключения создаются классы отправителя и получателя сообщений, см. рис.~\ref{fig:libbroker}. \subsection{Реализация на языке Go} В качестве библиотеки AMQP используется streadway/amqp~\cite{streadwayamqp}. Также используется официальная реализация Google~Protocol~Buffers~\cite{golangprotobuf}. Исходный код делится на 2 пакета: \begin{itemize} \item \textbf{service} -- обработка запросов и ответов; \item \textbf{worker} -- запуск модулей. \end{itemize} \subsection{Реализация на языке Python} В качестве библиотеки AMQP используется pika~\cite{pika}. Также используется официальная реализация Google~Protocol~Buffers~\cite{protobuf}. Исходный код делится на 2 пакета: \begin{itemize} \item \textbf{service} -- обработка запросов и ответов; \item \textbf{worker} -- запуск модулей. \end{itemize} \subsection{Реализация на языке C\#} В качестве библиотеки AMQP используется RabbitMQ~.NET~client~\cite{rabbitmqdotnet}. Также используется неофициальная реализация Google~Protocol~Buffers~\cite{protobufnet}. Выбор обусловлен идиоматической реализацией создания структур данных, что упрощает создание пользовательского интерфейса библиотеки. \section{Применение разработанных программных решений} Разработанный RPC успешно применяется в олимпиадной системе BACS. Он используется в сервисе тестирования решений для передачи пользовательских решений в кластер серверов для обработки. Каждое решение тестируется при помощи специальных модулей, создаваемых автоматически для каждой имеющейся в системе задачи. Модули генерируются Архивом задач на основе данных самих задач и помещаются в репозиторий. Сервисы BACS скачивают модули из репозитория при помощи библиотеки bunsan::pm~\cite{bunsanpm} и применяют их для тестирования задач. Общая схема работы системы представлена на рисунке~\ref{fig:bacsservice}. \begin{figure}[H] \centering \input rs/bacsservice.dot \caption{Сервисы системы BACS} \label{fig:bacsservice} \end{figure} \subsection{Производительность сервиса тестирования решений} Основным показателем эффективности сервиса тестирования решений является его производительность. Она измеряется в среднем количестве проверенных решений в секунду. Для оценки производительности был проведён эксперимент. Целью эксперимента является оценка производительности разработанного RPC, для этого была использована классическая олимпиадная задача "A+B", состоящая в сложении двух чисел. Время тестирования решений по этой задаче пренебрежимо мало, меньше 100мс, далее будет показано, что этим можно пренебречь. В ходе эксперимента было сделано 10000 запросов. Для каждого запроса было измерено время между отправкой запроса и до получения ответа на него. На рисунке~\ref{fig:performance} приведена схема распределения времени выполнения запроса. Среднее время выполнения одного запроса составляет $\mu = \frac{\sum_{i=1}^N t_i}{N} = 1.975$ секунд, среднеквадратичное отклонение $\sigma = \sqrt{\frac{\sum_{i=1}^N \left(t_i - \mu\right)^2}{N}} = 0.229$ секунд. Полученная схема соответствует нормальному распределению с параметрами $\mu = 1.975$ секунд и $\sigma = 0.229$ секунд. Исходя из полученных данных время проверки решения 0.1 секунды это 5\% от среднего времени работы, а среднее отклонение 12\%, а значит временем проверки решения можно пренебречь. \begin{figure}[H] \centering \includegraphics[width=\columnwidth]{rs/performance} \caption{Производительность} \label{fig:performance} \end{figure} \section{Выводы} \begin{itemize} \item Представлена архитектура реализации созданного во второй главе протокола RPC. \item Показаны особенности реализации протокола для конкретных платформ: Go, Python и C\#. \item Представлены результаты оценки производительности RPC. Получены численные результаты, произведён их анализ. \end{itemize} % vim: spell spelllang=ru \chapter{Разработка моделей использования RPC} В главе подробно рассматриваются связи между удалёнными компонентами олимпиадной системы BACS и требования к ним. Разрабатывается протокол асинхронного RPC на основе системы очередей сообщений. \section{Синхронные RPC} Архив задач является одним из важнейших компонентов олимпиадной системы. Он содержит все задачи, которые используются для проведения соревнований. Без задач работа системы не имеет смысла. Задача представляет из себя набор файлов в определённом формате, Архив предоставляет унифицированный интерфейс доступа к задачам вне зависимости от формата. Различным частям олимпиадной системы важны разные компоненты задачи, в частности Web-интерфейсу необходимо запрашивать метаинформацию: имя задачи, параметры тестирования, авторов. Подобная информация имеет ряд характерных особенностей: \begin{itemize} \item размер сильно ограничен, обычно до 1 мегабайта; \item присутствует у каждой задачи вне зависимости от формата; \item в случае обновления необходимо незамедлительно обновлять данные Web-интерфейса, выдавать пользователю устаревшие данные недопустимо. \end{itemize} \subsection{Интерфейс Архива задач} Интерфейс Архива задач состоит из двух частей. Первая часть это интерфейс администратора. Он позволяет добавлять, изменять и скачивать задачи. Вторая часть это запросы, которые обычно инициируются Web-интерфейсом системы: получение списка всех задач, подробной и краткой информации об определённых задачах. В обоих случаях важна производительность каждого запроса. Если же ответ на запрос не может быть доставлен, то необходимости повторять попытку нет, так как скорее всего данные устарели, по этой причине персистентность не является требованием. \subsection{Обоснование gRPC} При добавлении задачи в архив передаётся большое количество бинарных данных. Поэтому их кодирование в текстовых представлениях не является эффективным, XML-RPC или JSON-RPC применять не следует. Выбор был остановлен на gRPC. Эта реализация RPC позволяет эффективно организовать передачу данных, а также их хранение без изменения представления при помощи Google Protocol Buffers. \section{Асинхронные RPC} В отличие от запросов к Архиву задач, при тестировании решения особенности работы существенно отличаются. \begin{figure}[H] \centering \includegraphics[width=\columnwidth]{rs/submit} \caption{Решение в системе BACS} \label{fig:submit} \end{figure} На рисунке~\ref{fig:submit} представлен пример поведения пользователя и системы при обработке решения. В представленном сценарии пользователь отправляет в систему решение, которое передаётся Web-интерфейсом на сервер проверки. Время тестирования решения неизвестно, потому полезно информировать пользователя о текущем состоянии проверки. При обновлении страницы пользователь увидит что происходит с его решением в данный момент времени. Необходимо иметь ввиду, что пользователей может быть неопределённое количество, а значит множество решений может находиться на проверке в один момент времени. Помимо этого, проверка решения может занимать неопределённое время, обычно до нескольких минут. Выделять на каждого пользователя отдельный процесс обработки решения в Web-интерфейсе нецелесообразно, потому применение синхронных RPC не представляется возможным. Необходима реализация RPC, которая будет контролировать передачу данных в фоне -- асинхронно, при этом допуская временную недоступность узлов (Web-интерфейса или сервера проверки), чтобы ресурсоёмкие операции не приходилось повторять заново, то есть имела свойство персистентности. В ходе анализа показано, что ни одна из рассмотренных реализаций RPC не решает проблему персистентности. В данной работе рассматривается реализация асинхронного персистентного RPC протокола. \section{Разработка протокола} \subsection{Требования к протоколу} Для олимпиадной системы BACS необходимо разработать протокол передачи сообщений, который будет обладать следующими свойствами: \begin{itemize} \item надёжность и персистентность: если запрос не был обработан, в том числе по причине отказа принимающей стороны, а также если ответ на запрос временно не может быть доставлен, протокол должен повторять попытки; \item асинхронность: в один и тот же момент времени может обрабатываться неопределённое количество запросов, ответы на них возвращаются по мере выполнения запросов (но сохранение порядка неважно); \item переносимость: протокол должен иметь возможность быть реализованным для различных платформ и языков программирования; \item балансировка нагрузки: протокол должен поддерживать дубликацию сервисов; \item диагностика неисправностей: протокол должен содержать механизм для обработки ошибок. \end{itemize} Набор требований к RPC позволяет в качестве основы для реализации использовать систему очередей сообщений. Очередь сообщений позволяет передавать сообщения между различными компонентами распределённой системы, беря на себя заботу о сохранности данных и их доставки. \subsection{Выбор очереди сообщений} При выборе очереди сообщений важно учитывать популярность и стандартизованность реализации. При анализе были рассмотрен следующие очереди сообщений. \textbf{Apache ActiveMQ} -- это брокер сообщений с открытым исходным кодом, реализующий Java Message Service. Обеспечивает кластеризацию и хранение сообщений в различных базах данных, кэширование, ведение журналов. \textbf{Apache Kafka} -- это распределённый брокер сообщений, спроектированный для высокой масштабируемости. \textbf{RabbitMQ} -- это платформа, реализующая обмен сообщениями между компонентами системы на основе протокола AMQP~\cite{amqp}. Имеет множество библиотек на различных платформах и языках программирования для доступа к брокеру сообщений: C++, Java, .NET, Perl, Python, Ruby, PHP, Go. Поддерживает горизонтальное масштабирование. Выбор был остановлен на RabbitMQ по причине большей распространённости~\cite{mqcomparison}, использования протокола AMQP, а значит лучшей гарантии поддержки или простоты замены в будущем брокера сообщений. \subsection{Модель RPC} Протокол RPC строится на основе системы очередей сообщений. Каждый RPC два основных сообщения: запрос и ответ, а также опциональные статусные сообщения -- краткие описания текущего состояния. Протокол RPC делится на два уровня: представление данных и транспортный. На уровне представления данных передаётся служебная информация, такая как информация о получателе и отправителе, пользовательский запрос или ответ, информация об успешности выполнения запроса или ошибки. Транспортный уровень строится на основе системы очередей сообщений. В рамках данного протокола как отправитель запроса, так и его получатель являются клиентами по отношению к брокеру сообщений. Тем не менее для удобства именования рассматривается весь протокол в целом, потому отправитель запроса называется клиентом, а получатель -- сервисом. \subsubsection{Особенности RabbitMQ} Платформа RabbitMQ обладает рядом особенностей, которые необходимо учитывать при использовании в качестве транспортного уровня. Правильный выбор параметров очередей и самих сообщений позволяет добиться высокой надёжности и эффективности. Для каждого клиента выделяется две постоянные очереди для получения результатов и сообщений о критических ошибках. Вторая очередь необходима для тех случаев, когда передача сообщения об ошибке невозможна посредством первой очереди. К примеру, если сервис не смог раскодировать запрос из-за ошибки кодирования или несоответствия формата. В таком случае проблема может быть связана с несоответствием версий сервиса и клиента, и информация должна быть передана максимально надёжным способом -- в виде текста без использования протоколозависимого представления. Подобного рода критические ошибки не могут быть обработаны протоколом автоматически и предполагается вмешательство извне для их устранения, к примеру системным администратором. Особенность постоянных очередей в RabbitMQ является их сохранность при перезапуске брокера сообщений или его клиента. Сообщение, будучи сохранённым в очередь, должно быть передано для обработки при первой возможности. Временная недоступность сети, клиента или самого брокера не должно приводить к потере сообщения. Каждая из постоянных очередей и сообщений в них помечаются параметром durable=true, который гарантирует их хранение в постоянной памяти компьютера. При чтении сообщений из этих очередей используется режим с подтверждением обработки сообщений noAck=false. После того, как сообщение было обработано и, к примеру, сохранено в базе данных клиента, брокер должен получить подтверждение. Только после этого сообщение будет удалено из очереди навсегда. Если же подтверждение не получено, то после отключения клиента от брокера сообщение помещается в очередь заново. Это позволяет не беспокоиться о сохранности сообщений в случае аварийного завершения клиента. Помимо двух постоянных очередей клиент создаёт временную очередь статусов. Статус -- это специальное сообщение, которое содержит информацию о текущем состоянии выполнения запроса. Характер использования очереди статусов кардинально отличается от использования постоянных очередей. Здесь в первую очередь важна не сохранность сообщений, а скорость их доставки. Статус не влияет на логику работы системы и быстро устаревает. В первую очередь он необходим для пользователя, который хочет иметь возможность наблюдать состояние выполнения запроса. Можно заметить, что хранить больше одного состояния смысла нет. Также устаревшие состояния не имеют смысла, потому очередь, как и все сообщения в ней, помечаются параметром durable=false, а также для очереди устанавливается параметр autoDelete=true, который указывает, что брокер будет удалять очередь при отключении клиента. Попытка доставить сообщение в несуществующую очередь ведёт к его удалению, что и требуется для временных сообщений. \subsection{Модель протокола} \begin{figure}[H] \centering \input rs/brokerproto.dot \caption{Модель протокола} \label{fig:brokerproto} \end{figure} Протокол предусматривает наличие нескольких сервисов в системе одновременно. Каждый сервис имеет уникальное имя, но при этом сервис может быть продублирован для обеспечения надёжность в случае сбоя одной или нескольких его копий. При сбое необходимо перенаправить все необработанные сообщения на работающие копии сервиса. Эта задача решается при помощи использования одной постоянной очереди на сервис. Она создаётся при подключении первой из копий и используется всеми последующими копиями. При чтении из очереди сообщения распределяются равномерно между сервисами. Аналогично клиенту, постоянная очередь и все сообщения, помещаемые в неё помечаются параметром durable=true, а для чтения сообщений используется режим noAck=false, то есть необходимо подтверждение обработки сообщения. Так как результатом обработки сообщения является отправка ответа на него, подтверждать обработку следует только после помещения ответа в очередь результатов или ошибок. Следует заметить, что возможен сценарий, при котором сообщение может быть обработано несколько раз, ответ отправлен несколько раз, но подтверждение обработки запроса не отправлено. Поэтому задачей клиента является корректная обработка множественных ответов на один и тот же запрос. Эта проблема является распространённой в распределённых системах и корректная обработка множественных ответов или использование идемпотентных запросов, то есть таких, выполнение которых повторно не приводит к изменению состояния, является повсеместной практикой~\cite{distributed}. \subsubsection{Содержание сообщений} В рамках платформы RabbitMQ сообщение это массив байт с дополнительной метаинформацией, содержащей параметры хранения сообщения. Так как в протоколе требуется передача дополнительной информации, к примеру, имена очередей клиента для ответа, необходим метод кодирования информации в массив байт. Этот процесс называется сериализацией. Сериализацией в программировании называют процесс перевода какой-либо структуры данных в последовательность битов. Процесс восстановления закодированного сообщения из последовательности битов называется десериализацией. Для сериализации и десериализации выбрана библиотека Google Protocol Buffers. Выбор связан с её использованием совместно с gRPC в других частях системы. Google Protocol Buffers -- включает в себя язык описания структур данных, которые могут быть сериализованы и десериализованы. Для удобства изменения структуры разделены на два уровня. Первый уровень это независимое от RabbitMQ представление данных самих запросов и ответов, второй же уровень включает вспомогательную информацию, специфичную для RabbitMQ. Запрос описывается структурой Task (задание), которая содержит название сервиса worker, имя модуля этого сервиса package, который отвечает за обработку конкретного типа запроса, а также сам запрос в поле data. Статус (структура Status) содержит целочисленный код состояния code, используемый для кодирования типа состояния, краткое описание типа состояния reason, а также вспомогательная информация data. Результат (структура Result) содержит тип результата в поле status, его краткое описание в поле reason, результат работы в поле data если выполнение запроса завершилось без ошибок (status=OK), и журнал выполнения запроса в поле log. Виды состояний результатов: \begin{itemize} \item OK -- выполнение задания прошло успешно; \item ERROR -- произошла неизвестная ошибка при выполнении задания; \item PROTO\_ERROR -- ошибка связана с обработкой Google Protocol Buffers; \item WORKER\_ERROR -- ошибка связана с сервисом; \item UNKNOWN\_WORKER -- сервис неизвестен; \item INCOMPATIBLE\_PACKAGE -- модуль сервиса несовместим; \item PACKAGE\_ERROR -- ошибка модуля сервиса; \item PACKAGE\_NOT\_FOUND -- модуль не найден; \item PACKAGE\_BUILD\_ERROR -- ошибка инициализации модуля; \item EXECUTION\_ERROR -- ошибка выполнения модуля; \item EXECUTION\_TIMEOUT -- превышено время выполнения модуля.. \end{itemize} \lstinputlisting[title="Структуры данных"]{modules/broker/include/bunsan/broker/protocol.proto} Для передачи описанных выше структур данных используются дополнительные структуры-обёртки, содержащие служебную информацию для маршрутизации в RabbitMQ. Для структуры-задания добавляются идентификатор сообщения, дополнительные ограничения на сервис, а также имена очередей для ответа. Для структур статуса и результата добавляется только идентификатор сообщения. \lstinputlisting[title="Структуры данных для RabbitMQ"]{modules/broker/include/bunsan/broker/rabbit/connection.proto} \section{Выводы} \begin{enumerate} \item Проанализированы синхронные RPC, применяемые при взаимодействии Web-интерфейса и Архива задач, построена их модель, обоснован выбор gRPC для реализации представленной модели. \item Проанализированы асинхронные RPC, применяемые при взаимодействии Web-интерфейса и системы тестирования, построена их модель, предложен протокол для реализации представленной модели, обоснован выбор Google Protocol Buffers и RabbitMQ для реализации предложенного протокола. \end{enumerate} % vim: spell spelllang=ru \begin{titlepage} \thispagestyle{empty} \begin{center} \large Ижевский государственный технический университет\\* имени М.Т. Калашникова \vspace{1cm} \end{center} \vspace{8em} \begin{center} \large \textbf{Самостоятельная работа\\* «Компоненты диссертации»}\\* Направление подготовки: 09.04.04 - Программная инженерия\\* Кафедра - Программная инженерия \end{center} \vspace{7em} \begin{flushleft} Выполнил магистрант \hfill \myname \vspace{2em} Научный руководитель,\\* \myteacherdegree \hfill \myteacher \vspace{2em} Проверил\\* д.т.н., профессор \hfill С.Г. Селетков \vspace{2em} \hfill «19» мая 2016 г. \end{flushleft} \vspace{\fill} \begin{center} Ижевск \myyear \end{center} \end{titlepage} \setcounter{page}{2} \pagestyle{plain} % vim: spell spelllang=ru \documentclass[12pt]{report} \usepackage{xltxtra} \usepackage{polyglossia} \setdefaultlanguage[spelling=modern]{russian} \setmonofont[Mapping=tex-text]{Liberation Mono} \setmainfont[Mapping=tex-text]{Liberation Serif} \input dot2tex \usepackage[titletoc]{appendix} \usepackage{etoolbox} \usepackage{caption} \usepackage{verbatim} \usepackage{tabularx} \usepackage{float} \usepackage{url} \usepackage{indentfirst} \setlength{\parindent}{1.5cm} \usepackage{algorithm} \usepackage{algorithmic} \input style \expandafter\def\expandafter\UrlBreaks\expandafter{\UrlBreaks \do\a\do\b\do\c\do\d\do\e\do\f\do\g\do\h\do\i\do\j \do\k\do\l\do\m\do\n\do\o\do\p\do\q\do\r\do\s\do\t \do\u\do\v\do\w\do\x\do\y\do\z\do\A\do\B\do\C\do\D \do\E\do\F\do\G\do\H\do\I\do\J\do\K\do\L\do\M\do\N \do\O\do\P\do\Q\do\R\do\S\do\T\do\U\do\V\do\W\do\X \do\Y\do\Z} \chapter*{Реферат} \textbf{Объем и структура диссертационной работы.} Диссертация содержит введение, три главы, заключение и одно приложение, изложенные на 103 страницах машинописного текста. В работу включены 7 рисунков, список литературы из 23 наименований. В приложении представлены основные фрагменты исходного кода реализации разработанного RPC протокола. В исследовании проведен обзор, сравнение и анализ программных средств, реализующих удалённый вызов процедур. Выделены характерные особенности систем RPC и требования, предъявляемые к ним. Разработан асинхронный протокол RPC на основе системы очередей сообщений RabbitMQ. Создана реализация протокола для языков программирования Go, Python и C\#. Произведена оценка производительности полученного протокола на основе эксперимента. \textbf{Ключевые слова:} распределённые системы, удалённый вызов процедур, модели RPC, очередь сообщений, система проведения олимпиад. % vim: spell spelllang=ru \appendix \begin{appendices} \renewcommand*{\thechapter}{\arabic{chapter}} \titleformat{\chapter}[hang] {\normalfont\raggedleft} {\MakeUppercase{\appendixname} \thechapter} {1em} {\\*\centering\uppercase{#1}} \input rs/sourcecode.sh \end{appendices} %================ % Разметка страницы \usepackage{fancyhdr} \fancypagestyle{plain}{ \fancyhf{} \fancyhead[R]{\thepage} \renewcommand{\headrulewidth}{0pt} \renewcommand{\footrulewidth}{0pt} } %================ % Остальное \renewcommand{\baselinestretch}{1.5} \frenchspacing \newcommand{\myenquote}[1]{``#1''} %================ % Формат списков \renewcommand{\labelenumi}{\arabic{enumi})} \renewcommand{\labelenumii}{\arabic{enumi}.\arabic{enumii})} \renewcommand{\labelenumiii}{\labelenumii\arabic{enumiii})} \renewcommand\textbullet{--} %================ % Формат области печати \usepackage[a4paper]{geometry} \geometry{left=3cm} \geometry{right=1cm} \geometry{top=2cm} \geometry{bottom=2cm} %================ % Формат заголовков \usepackage[explicit]{titlesec} \AtBeginDocument{ \renewcommand{\contentsname}{Содержание} \renewcommand{\bibname}{Список литературы} } \renewcommand{\appendixname}{Приложение} \renewcommand{\thefigure}{\arabic{chapter}.\arabic{figure}} \renewcommand{\theequation}{\arabic{equation}} \setcounter{secnumdepth}{4} %\let\appendix\chapter \titleformat{\chapter}[hang] {\normalfont\center} {\thechapter.} {1em} {\uppercase{#1}} \titlespacing{\chapter} {0cm} %left {-2em} %before {1cm} %after \titleformat{\section}[hang] {\normalfont} {\thesection.} {1em}{#1} \titlespacing{\section} {1.5cm} %left {1.5em} %before {0.5cm} %after \titleformat{\subsection}[hang] {\normalfont} {\thesubsection.} {1em}{#1} \titlespacing{\subsection} {1.5cm} %left {1.5em} %before {0.5cm} %after \titleformat{\subsubsection}[hang] {\normalfont} {\thesubsubsection.} {1em}{#1} \titlespacing{\subsubsection} {1.5cm} %left {1em} %before {1em} %after \titleformat{\paragraph}[runin] {\normalfont} {\theparagraph.} {1em}{#1} \titlespacing{\paragraph} {1.5cm} %left {1em} %before {1ex} %after %================== % Оглавление \usepackage{tocloft} \usepackage{etoolbox} \renewcommand{\cftchapaftersnum}{.} \renewcommand{\cftsecaftersnum}{.} \renewcommand{\cftsubsecaftersnum}{.} \renewcommand{\cftsubsubsecaftersnum}{.} \renewcommand{\cftparaaftersnum}{.} \renewcommand{\cftchappagefont}{\mdseries} \renewcommand{\cftpartleader}{\cftdotfill{\cftdotsep}} \renewcommand{\cftchapleader}{\cftdotfill{\cftdotsep}} \makeatletter \patchcmd{\l@chapter} {\cftchapfont #1} % search pattern {\cftchapfont {#1}} % replace by {} % success {} % failure \makeatother \renewcommand\cftchapfont{\mdseries\MakeUppercase} \makeatletter \patchcmd{\@cftmaketoctitle} {\cfttoctitlefont\contentsname} {\cfttoctitlefont{\contentsname}} {} {} \makeatother \renewcommand{\cfttoctitlefont}[1]{\large\centering\MakeUppercase{#1}\par} \setlength{\cftbeforechapskip}{0.5em} \setlength{\cftbeforesecskip}{0.5em} \setlength{\cftbeforesubsecskip}{0.5em} \setlength{\cftbeforetoctitleskip}{-2em} %================== % Списки \usepackage{enumitem} \setlist{nolistsep} \setenumerate[0]{leftmargin=2cm} \setenumerate[1]{leftmargin=2cm} \setenumerate[2]{leftmargin=1cm} \setitemize[0]{leftmargin=2cm} %================== % Код \usepackage{listings} \lstset{ % language=C++, % the language of the code basicstyle=\ttfamily\footnotesize,% the size of the fonts that are used for the code numbers=left, % where to put the line-numbers numberstyle=\footnotesize, % the size of the fonts that are used for the line-numbers stepnumber=2, % the step between two line-numbers. If it's 1, each line % will be numbered numbersep=5pt, % how far the line-numbers are from the code %backgroundcolor=\color{white}, % choose the background color. You must add \usepackage{color} showspaces=false, % show spaces adding particular underscores showstringspaces=false, % underline spaces within strings showtabs=false, % show tabs within strings adding particular underscores frame=single, % adds a frame around the code tabsize=2, % sets default tabsize to 2 spaces captionpos=b, % sets the caption-position to bottom breaklines=true, % sets automatic line breaking breakatwhitespace=false, % sets if automatic breaks should only happen at whitespace title=\lstname, % show the filename of files included with \lstinputlisting; % also try caption instead of title escapeinside={\%*}{*)}, % if you want to add a comment within your code morekeywords={*,...} % if you want to add more keywords to the set } \input head \renewcommand{\baselinestretch}{1.3} \setlength{\lineskiplimit}{-10cm} \begin{document} \begin{titlepage} \thispagestyle{empty} \begin{center} \large \textbf{\uppercase{Рецензия}} \vspace{1em} На диссертацию Филиппова А.Н. <<Модели RPC в проектировании олимпиадного сервера>> представленную на соискание степени магистра по~направлению~09.04.04-1 \\* <<Разработка программно-информационных систем>> \end{center} \vspace{2em} Диссертация Филиппова А.Н. состоит из введения, 3-х глав, заключения и приложения. Во введении показана актуальность темы диссертации, изложен объект исследования, предмет исследования и цель работы, перечислены научно-технические задачи, необходимые для решения поставленной цели и представлены результаты работы, выносимые на защиту. В первой главе выполнен обзор существующих методов межпроцессных взаимодействий, приведена классификация систем вызова удалённых процедур и обоснованы задачи, сформулированные во введении. Вторая глава посвящена разработке моделей вызовов удалённых процедур в олимпиадном сервере, а также разработке протокола асинхронного вызова удалённых процедур. В третьей главе рассмотрена реализация протокола RPC, разработанного во второй главе, представлено применение полученной реализации в олимпиадном сервере. В заключении диссертационной работы сформулированы основные выводы и результаты выполнения работы. В приложении приведены тексты разработанного программного обеспечения. Структура и предложенные решения обоснованы, выполнены с технической и научной точки зрения грамотно, и правильность предложенных решений подтверждена экспериментально. Тем не менее, работа имеет недостаток. Не смотря на обоснование использования централизованных систем очередей сообщений, в представленной работе упущено описание одноранговых моделей передачи сообщений. Несмотря на указанный недостаток, диссертационная работа Филиппова А.Н. является завершенным научным исследованием, выполненным на актуальную тему. Положения, вынесенные автором на защиту, обладают научной новизной и практической ценностью. Рассмотренная работа соответствует требованиям, предъявляемым к магистерским диссертациям, и заслуживает оценки "отлично", а ее автор — присуждения степени магистра. \vfill \noindent Рецензент \\* д.ф. - м.н. \hfill М.М. Горохов \end{titlepage} \end{document} % vim: spell spelllang=ru