gazya.ru страница 1
скачать файл

Допустить к защите в ГАК

Заведующий кафедрой информационной безопасности

д.т.н. профессор

А.А. Захаров

(подпись)

«___» ________20__ г.


Краснов Евгений Сергеевич

РАЗРАБОТКА ЗАЩИЩЁННОЙ РАСПРЕДЕЛЁННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ

«ИНСТРУМЕНТЫ ДЛЯ ЗАРАБОТКА НА СТАВКАХ»

(Выпускная квалификационная работа)

Научный руководитель:

к.т.н.


/О.А. Нестерова/

(подпись)

Автор работы:



/Е.С. Краснов/

(подпись)

Содержание


Введение 3

1. Постановка задачи. Разработка системы 6

1.1. Описание предметной области. Обзор существующих аналогов 6

1.2. Проектирование структуры информационной системы 7

1.3. Разработка серверной и клиентской части 9

1.4. Выводы по главе 1 16

2. Оптимизация работы системы 17

2.1. Оптимизация алгоритма обработки данных 17

2.2. Оптимизация протокола передачи данных 22

2.3. Масштабируемость 24

2.4. Итоговая схема информационной системы 25

2.5. Выводы по главе 2 26

3. Анализ угроз информационной безопасности 27

3.1. Модель потенциального нарушителя 27

3.2. Определение возможных угроз 28

3.3. Защита от возможных угроз 28

3.4. Выводы по главе 3 36

4. Модернизация клиентской части. Дальнейшая поддержка системы 37

4.1. Развитие клиентского приложения 37

4.2. Поддержка работы системы 48

4.3. Оценка эффективности 49

4.4. Выводы по главе 4 50

Заключение 51

Список использованной литературы 52

Приложение 55


Введение


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

Дипломный проект посвящён разработке такого сервиса. Основная его функция – сравнение данных на сайтах букмекерских контор, выявление разности коэффициентов (далее арбитражная ситуация), которая позволит конечному пользователю получить выгоду. За 3 года работы число подключённых сайтов достигло 100 – а это десятки тысяч матчей и миллионы ставок, проверяемые каждую секунду. Высокая частота проверки вызвана тем, что многие букмекеры применяют алгоритмы противодействия возникновению арбитражных ситуаций и могут изменить коэффициент уже через несколько секунд.

Актуальность темы дипломной работы определяется необходимостью оптимизации и защиты информационных систем, обрабатывающих большой объём данных и требующих высокой скорости обработки.

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

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

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



  1. спроектировать структуру информационной системы;

  2. разработать серверную и клиентскую части;

  3. выбрать метод лицензирования клиентского приложения;

  4. оптимизировать алгоритма обработки данных;

  5. оптимизировать протокол передачи данных от сервера клиентскому приложению;

  6. обеспечить безопасность системы;

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

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

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

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

Практическая значимость работы определяется тем, как именно можно применить найденные способы оптимизации и защиты в конкретной информационной системе.

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

Наиболее существенные результаты, полученные в процессе исследования:



  1. обработка данных в информационной системе ускорена почти в 200 раз;

  2. получена возможность масштабирования серверной части;

  3. оптимизирован протокол передачи данных между компонентами информационной системы;

  4. определены подходящие методы защиты системы в области информационной безопасности.

1. Постановка задачи. Разработка системы

1.1. Описание предметной области. Обзор существующих аналогов


Для начала рассмотрим суть действия арбитражной ситуации [1]. Предположим, что в двух букмекерских конторах есть отличающиеся коэффициенты на ставки. Распределение коэффициентов у букмекеров А и Б представлено в таблице 1.
Таблица 1. Распределение коэффициентов

Букмекерская контора

Победа теннисиста №1

Победа теннисиста №2

A

1.28

3.6

Б

1.5

2.91

Общие средства на ставки составляют $100.

В конторе А производится ставка $30 на победу №2, а в конторе Б – $70 на победу №1. Распределение сумм ставок представлено в таблице 2.
Таблица 2. Распределение сумм ставок


Ставка

Победа теннисиста №1

Победа теннисиста №2

Букмекер А

$0

$30

Букмекер Б

$70

$0

Первый возможный исход: побеждает теннисист №1 (выигрыш в конторе Б). $70 * 1.5 = $105, тогда прибыль составит 5$.

Второй возможный исход: побеждает теннисист № 2 (выигрыш в конторе А). $30 * 3.6 = $108, тогда прибыль: 8$.

Распределение сумм выплат представлено в таблице 3.


Таблица 3. Распределение сумм выплат

Выплата

Победа теннисиста №1

Победа теннисиста №2

Букмекер А

$0

$105

Букмекер Б

$108

$0

Подобный способ заработка известен мало, однако он стабилен, и существуют десятки сервисов, предоставляющих информацию об арбитражных ситуациях [2]. Помимо рассмотренного в работе, на рынке присутствует 3 наиболее качественных сервиса. В таблице 4 приведено сравнение сервисов арбитражных ситуаций по наиболее значимым критериям.


Таблица 4. Сравнение сервисов арбитражных ситуаций

Название

SureBet

AllBestBets

RebelBetting

Число букмекеров

56

34

38

Средний период обновления данных, сек

100

200

30

Примерное число комбинаций

1000

800

300

Способ доставки информации

Web-сайт

Web-сайт

Приложение

Встроенный браузер

-

-

+

Год запуска

2009

2012

2009

Число разработчиков

4

4

8

Стоимость, руб./месяц

1000

800

5000



1.2. Проектирование структуры информационной системы


При первоначальном создании системы планировалось включить в работу только 20 букмекерских контор, поэтому определено несколько простейших модулей:

  1. сервер загрузки – первоначальный сбор данных о ставках с сайтов букмекеров и передача их на главный сервер;

  2. прокси-сервера – обход блокировок по IP-адресу, которые возникали при частых запросах к сайтам;

  3. главный сервер – обработка полученных данных, поиск арбитражных ситуаций;

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

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

На рисунке 1 приведена структура информационной системы. Стрелками обозначены направления передачи данных.



Рисунок 1. Первоначальная структура информационной системы

1.3. Разработка серверной и клиентской части


Для разработки использована среда Visual Studio 2008 (в последствии – Visual Studio 2010) [3]. В ней на языке C# [4] написана программная сторона серверной части, а также клиентское приложение.

1.3.1. Сервер


Изначально, согласно схеме из рисунка 1, серверная часть состояла из двух серверов. Так как объём обрабатываемых данных был невелик, были выбраны простейшие VPS сервера на ОС Windows Server 2008 R2 [5]. Они имели 512 МБ ОЗУ, частоту процессора 800 МГц и дисковое пространство в размере 20 ГБ.

Структуры, определённые для использования и передачи между серверами, приведены в приложении.

У каждой структуры присутствует прямая ссылка на сайт. Сделано это по той причине, что разные букмекеры имеют разные уровни прямой адресации. Чем ниже уровень объекта, для которого доступна прямая ссылка, тем лучше – это экономит время поиска коэффициента пользователем. У некоторых букмекеров же вообще нет прямых ссылок, и положение спасает только встроенный в клиентское приложение браузер (см. пп. 4.1.2).

Упрощённые названия команд представляют собой копии обычных названий, которые дополнительно приведены к простому виду для сравнения с матчами у других букмекеров (подробнее описано в пп. 2.1.2). Для этого же предназначалось и упрощённое название чемпионата.

Более подробное описание использования структур приведено в пп. 1.3.1.1 и 1.3.1.2.

1.3.1.1. Сервер загрузки


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

  1. загрузка напрямую с сайта – на одной или нескольких (не более 10) страницах сайта отображаются сразу все чемпионаты, матчи и ставки. Их считывание происходит последовательно. При блокировке IPадреса начинают использоваться прокси-серверы;

  2. более сложная загрузка напрямую с сайта – каждый чемпионат, матч или ставка располагаются на отдельной странице сайта. Считывание происходит параллельно в 5-100 потоков (их число зависит от объёма загружаемых данных и скорости работы сайта). Всегда используются прокси-серверы, потому что такое число запросов с одного IP-адреса блокируется почти моментально;

  3. загрузка через XML файл [6]. Некоторые букмекеры предоставляют (публично, или по договоренности) возможность загружать все данные одним запросом в удобном виде, что значительно облегчает задачу.

В первоначальном варианте сайты загружались последовательно, по кругу, что занимало около 10 минут, однако затем была проведена оптимизация для возможности параллельной работы. Она заключалась в следующем: загрузка всех сайтов разделена на несколько потоков (от 1 до 4 сайтов на поток в зависимости объёма загружаемых данных), которые стали выполняться одновременно, что значительно сократило задержку на получение данных со всех сайтов.

Каждый модуль загрузки преобразует данные с конкретного с сайта в множество объектов типа «Букмекер» (см. пп. 1.3.1). Рассмотрено два варианта сериализации [7] объектов:



  1. использование публично доступных сериализаторов в стандартный вид разметки (XML, JSON) [8, 9];

  2. написание собственного сериализатора, приспособленного под конкретные структуры данных.

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

После сериализации данные сохраняются в виде файла. При этом используется сжатие GZip [10] – эксперимент показал, что процедура «архивация - передача по сети - разархивация» производится быстрее, чем передача несжатых данных2. Полученный файл хранится в папке, откуда главный сервер с помощью FTP загружает его и десериализует.


1.3.1.2. Главный сервер


Работа главного сервера заключается в постоянном выполнении следующего цикла:

  1. загрузка данных с FTP-сервера;

  2. распаковка и десериализация;

  3. сравнение чемпионатов от разных букмекеров, распределение их по категориям;

  4. сравнение матчей от разных букмекеров внутри одной категории чемпионатов, разделение данных матчей также по группам;

  5. сравнение коэффициентов внутри каждой группы матчей, выявление арбитражных ситуаций;

  6. обработка арбитражных ситуаций, вычисление вспомогательных свойств (например, время с момента первого обнаружения).

Пункты 3 и 4 выполняются с помощью упрощённых названий. Изначальные названия команд и чемпионатов зачастую имеют совершенно разный вид у разных букмекеров (в том числе, написаны на разных языках). Данные названия переводятся на русский язык с использованием встроенного словаря, который до сих пор периодически дополняется вручную. Если подходящая запись в словаре не найдена, то производится транслитерация. Переведённые названия приводятся к упрощённому виду следующим образом:

  1. все прописные буквы заменяются на строчные;

  2. удаляются все пробелы и знаки препинания;

  3. некоторые буквосочетания заменяются на другие (например, «кс» на «х») – это сделано потому, что букмекеры часто применяют лексические правила не того языка при переводе3.

Сравнение названий происходит с помощью алгоритма поиска наибольшей общей подстроки [11] – определяется суммарная длительность всех совпадающих подстрок длиной от 5 символов. Используя найденную величину, алгоритм решает, считать ли сравниваемые строки похожими в зависимости от соотношения суммарной общей длины подстрок и длин самих строк. Это сделано потому, что названия одних и тех же чемпионатов и команд у разных букмекеров варьируются, и простое сравнение строк здесь несостоятельно.

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

В таком виде цикл работал несколько месяцев, но затем постепенно был значительно оптимизирован (подробнее описано в пп. 2.1).

1.3.2. Клиентское приложение


Первая версия клиентского приложения имела минимум функций. Было доступно следующее:

  • отображение списка с основной информацией по арбитражным ситуация;

  • выбор видов спорта, чемпионатов и минимального процента прибыли для фильтрации;

  • простейший калькулятор.

На рисунке 2 приведён снимок окна первой стабильной версии клиентского приложения.

c:\мои документы\картинки\screenshots\12.04.2011 shot0002.jpg

Рисунок 2. Первая стабильная версия клиентского приложения
Приложение создано на платформе .NET Framework версии 2.0 [12]. Главным аргументом против версии 3.5 являлось то, что у многих пользователей в то время была установлена ОС Windows XP, в которую встроен как раз .NET Framework 2.04.

Приложение получало данные с сервера по запросу, при нажатии кнопки «Обновить базу», при этом загружались все доступные на сервере арбитражные ситуации, и уже внутри приложения применялся фильтр по доступным критериям. Общий объём передаваемых данных был невелик – не более 50 КБ за раз.


1.3.3. Выбор метода лицензирования клиентского приложения


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

  1. разовая покупка с неограниченным сроком действия;

  2. ежемесячная подписка.

Второй вариант оказался более подходящим ввиду специфики сервиса, а именно:

  1. каждый пользователь при работе с приложением создаёт постоянную нагрузку на сервер;

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

В качестве базы для хранения учётных записей используется Microsoft SQL Server 2008 R2 [13].

На рисунке 3 приведён снимок окна входа приложение, где также можно зарегистрироваться, задать настройки прокси-сервера или восстановить утраченный пароль.



c:\мои документы\картинки\screenshots\07.01.2012 shot0011.jpg

Рисунок 3. Окно входа в приложение
На рисунке 4 приведён снимок окна регистрации в приложении.

c:\мои документы\картинки\screenshots\08.12.2013 shot0009.png

Рисунок 4. Окно регистрации

1.4. Выводы по главе 1


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

2. Оптимизация работы системы

2.1. Оптимизация алгоритма обработки данных


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

где:


n – среднее число матчей в каждой группе;

x – число групп матчей;

y – число итераций.

Такое отношение объясняется следующим образом: при анализе производится поиск арбитражных ситуаций по 2 и 3 ставкам. Число итераций определяется сочетанием из n по 2 и из n по 3 соответственно [14], где n – общее число матчей, которое увеличивается при добавлении нового букмекера.

Очевидно, что подключение каждого следующего букмекера увеличивает время обработки данных в геометрической прогрессии. Когда в сервисе присутствовало всего 30 букмекерских контор, алгоритм обработки был очень прост и не содержал в себе никаких оптимизаций, время обработки данных составляло около 10 секунд. Но с постепенным увеличением количества подключённых сайтов, которых сейчас уже 97, возникла необходимость в оптимизации алгоритмов и нахождении способов сокращения объёмов вычислений. Время обработки теперь составляет не более 2 секунд5.

2.1.1. Построение дерева категорий и групп


Сократить время обработка данных можно, если не выполнять полностью операции сравнения чемпионатов и матчей (пункты 3, 4 цикла) при каждом проходе путём создания дерева категорий чемпионатов и групп матчей. Для этого потребовалось внести изменения в структуры: для каждого чемпионата и матча определён уникальный идентификатор, который определляется расчётом хэш-значения основных атрибутов (для чемпионата – адрес сайта и название; для матча – идентификатор чемпионата, названия команд и дата начала). Таким образом, при первоначальном сравнении строится дерево категорий и групп, и во время следующих проходов цикла с помощью идентификаторов оно восстанавливается, а проверяются только новые чемпионаты и матчи, идентификаторы которых в дереве отсутствуют.

Эта простая оптимизация оказалась очень эффективной – время работы 3 и 4 этапа цикла снизилось примерно в 100 раз.


2.1.2. Ускорение передачи данных между серверами


Как было описано в пп. 1.3.1.1, данные для передачи приходится преобразовывать в строковой формат, а затем – обратно. Это занимает время. Но совсем необязательно каждый раз передавать полный набор данных, так как не все данные меняются при каждом их сохранении. Оптимизация этого этапа заключалась в следующем:

  1. сервер загрузки сохраняет два файла: один с полным набором данных, а второй – только с теми матчами, которые были изменены за последние 20 секунд6, для всех остальных матчей записываются только их идентификаторы;

  2. если предыдущее время работы цикла главного сервера составило меньше 17 секунд, то он загружает «облегчённый» файл данных;

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

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

  5. остальные матчи удаляются из набора.

Эта оптимизация позволила снизить как время передачи данных по сети (ввиду снижения объёма файла на порядок7), так и время на сериализацию-десериализацию. Благодаря этому, общее время работы данного этапа цикла снизилось примерно в 10 раз.

2.1.3. Ускорение поиска категорий


Изначально чемпионаты распределялись по категориям с использованием алгоритма выявления похожих строк (как описано в пп. 2.1.2). Но одна особенность позволила использовать другой, гораздо более быстрый алгоритм. Она заключается в том, что чемпионаты имеют древовидную структуру: вид спорта → страна → номер дивизиона → возраст (если чемпионат молодёжный) → пол (если чемпионат женский). Итак, с помощью определения присутствия в строке ключевых слов можно однозначно отнести чемпионат к конкретной категории. Дальнейшее разделение чемпионатов по категориям теперь происходит путём простого сравнения строк.

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


2.1.4. Оптимизация алгоритма сравнения строк


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

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

Предположим, что проверяется эквивалентность неких строк А и Б. После первоначального их сравнения алгоритм добавляет в специальный словарь запись «А+Б»=В, где В – результат проверки. Затем, когда те же строки попадут на вход алгоритма, то обнаружится соответствующая запись в словаре и сразу вернётся её результат.

Это изменение оказалось эффективным, так как одни и те же строки сравниваются между собой неоднократно. Алгоритм сравнения строк при этом стал выполняться в среднем в 20 раз быстрее, чем ранее. Можно заметить, что используется принцип, похожий на тот, что описан в пп. 2.1.3, с учётом специфики большой вариативности и разнообразия названий.


2.1.5. Оптимизация проверки групп


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

2.1.6. Оптимизация обработки полученных данных


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

  1. список больше не очищался после прохода цикла;

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

    1. если матч не найден;

    2. если матч найден и он был изменён.

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

2.1.7. Многопоточная обработка данных


При увеличении объёма информации естественным является переход со слабых VPS-серверов на многопроцессорные выделенные Intel Xeon. Однако в каждом процессоре несколько ядер, каждое из которых в свою очередь разделено на 2 потока. В результате, процессор при работе нагружен не более, чем на 6% (1/16 от всей мощности), поэтому эффект от перехода на мощное оборудование заметен слабо без проведения многопоточной обработки данных.

Для включения многопоточности выполнены следующие изменения:



  1. алгоритм поиска категорий остался прежним (см. объяснение в пп. 2.1.3).

  2. для алгоритма сравнения матчей все категории разделены на несколько подгрупп. Разделение проводилось достаточно равномерно путём круговой нумерации8 (категория с самым большим числом матчей относится к подгруппе №1, вторая по количеству – к подгруппе №2, и так по кругу). Число подгрупп равно числу потоков, и каждый поток работает со своей подгруппой, производя в ней сравнение матчей;

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

  4. все глобальные переменные сделаны потокобезопасными, например словарь из пп. 1.3.1.2. Очень кстати пришлись новые встроенные потокобезопасные классы из .NET Framework 4.0 (например, класс ConcurrentDictionary для словаря) [15].

2.2. Оптимизация протокола передачи данных


В первом рабочем варианте после каждого прохода цикла все арбитражные ситуации сохранялись в файл, и клиентское приложение скачивало его по запросу пользователя (при нажатии кнопки «Обновить»). Со временем выявилось несколько недостатков этого способа:

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

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

2.2.1. Создание дополнительного модуля отправки данных


Чтобы можно изменять набор данных, отправляемых приложению, выделен модуль отправки данных, который работает параллельно с основным рабочим циклом. Его работа заключается в следующем: после запуска модуль с помощью класса Socket открывает прослушивание 80-го порта9[16]. Приложение после нажатия кнопки «Обновить» отправляет HTTP-запрос также, как на обычный Web-сервер. Такая схема позволила провести необходимые оптимизации.

2.2.2. Отправка данных по фильтру


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

Следующие изменения были внесены в сервер:



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

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

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

2.2.3. Поддержка постоянного соединения


Использование класса Socket позволило не только прослушивать 80-й порт и обрабатывать HTTP-запросы, но и включить постоянный канал связи с клиентским приложением.

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


2.3. Масштабируемость


Масштабируемость является свойством информационной системы, позволяющим сохранять производительность системы на должном уровне при растущем объёме обрабатываемых данных с помощью увеличения количества вычислительных компонентов (серверов) [17].

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

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

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



  1. определение хэш-значения идентификатора группы;

  2. вычисление остатка от деления хэш-значения на число серверов обработки данных;

  3. присваивание группе номера сервера, соответствующего найденному остатку.

Для связи и передачи данных между серверами обработки и координирующим сервером использован класс Socket: он позволяет быстро передать через сеть любой объём данных и сразу получить ответ.

Таким образом, процедура сравнения матчей внутри категории на сервере обработки данных приняла следующий вид:



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

  2. формирование списка идентификаторов всех оставшихся матчей;

  3. соединение с координирующим сервером и отправка созданного списка;

  4. получение таблицы соответствия идентификаторов текущему серверу, а также конкретным идентификаторам групп;

  5. исключение из обработки данных всех матчей, помеченных для другого сервера;

  6. соотнесение оставшихся матчей и указанных идентификаторов групп.

2.4. Итоговая схема информационной системы


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



Рисунок 5. Итоговая схема информационной системы

2.5. Выводы по главе 2


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

3. Анализ угроз информационной безопасности

3.1. Модель потенциального нарушителя


В текущем состоянии системы следующий круг лиц может быть заинтересован в нарушении её информационной безопасности:

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

    1. приостановка работы системы из-за сбоя – в этом случае пользователи начнут искать альтернативные варианты;

    2. получение доступа к одному из серверов – в зависимости от выбранного сервера, нарушитель будет иметь возможность скопировать на свой компьютер часть кодовой базы – при её получении и дальнейшем изучении сотрудники конкурентного сервиса имеют возможность применить к своей системе многие используемые методы оптимизации и другие полезные части кода, а в худшем случае (доступ ко всем элементам кода) – создать полную копию серверной части информационной системы;

    3. декомпиляция приложения – так как в приложении не содержится важных и уникальных алгоритмов, единственный подходящий вариант использования его кода – создание и распространение модифицированной копии, которая, например, имела бы значительные изъяны и недостатки или была взломана для возможности бесплатного пользования;

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

  2. люди, считающие, что всё должно быть бесплатно – возможно два варианта:

    1. нарушитель может приложение декомпиляции для возможности модификации, (аналогично пункту 1в);

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

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

3.2. Определение возможных угроз


На основе модели нарушителя определён полный набор угроз безопасности:

  1. атаки на отказ;

  2. получение несанкционированного доступа к серверам;

  3. декомпиляция приложения, в том числе для нелегального использования;

  4. получение несанкционированного доступа к базе данных;

  5. подбор паролей для получения доступа к учётным записям пользователей;

  6. кража конфиденциальных данных пользователя из клиентского приложения;

  7. утеря исходного кода из-за сбоя/поломки физического носителя;

  8. сбой в работе сервера по другим причинам.

3.3. Защита от возможных угроз

3.3.1 Защита от атак на отказ


Основные направления атак на отказ могут быть следующими:

  1. web-сервер, который обрабатывает запросы входа в учётную запись, регистрации и некоторые другие, а также держит Web-сайт сервиса;

  2. собственный модуль отправки данных (см. пп. 2.2), который аналогично Web-серверу производит прослушивание порта.

Атаки на сетевом уровне (например, ICMP-flood) не рассматриваются, так как их защиту берёт на себя компания-собственник серверов, настроив соответствующим образом свои маршрутизаторы и другое сетевое оборудование.

Защиту от атак на Web-сервер производит дополнение IIS под названием «Dynamic IP Restrictions» [20]. Это позволяет блокировать соединения с IPадресов, число запросов с которых превышает указанный лимит, при этом настраивается не только лимит, но и срок блокировки. Однако, дополнение не защищает полностью от распределённых атак, когда используется так называемый «ботнет». В этом случае применяются более сложные решения, в частности CloudFlare [21].

Несколько другим образом формируется защита собственного модуля отправки данных. Хотя принципы защиты используются те же, но сам модуль представляет из себя нечто иное, чем Web-сервер, поэтому всю логику приходится писать самостоятельно, а не используя готовые продукты. Например, аналогично расширению IIS «Dynamic IP Restrictions», в памяти хранится список IP-адресов, запросы с которых происходили в последнюю секунду, и если с какого-либо адреса за этот период было более 5 запросов, то соединения от него блокируются на 1 минуту.

Защиту от распределённых атак можно выстраивать после начала одной из таких атак, когда уже проявляется её эффект в виде повышенной нагрузки и медленной работы системы. Как правило, все соединения из «ботнета» похожи между собой. Они обычно формируют запрос одинаковым образом – например, имеют одинаковые заголовки, периодичность запросов часто также одинакова. Таким образом, удаётся сформировать признаки, соединения по которым будут блокироваться.

В крайнем случае, если общие признаки запросов определить не удалось, придётся применять блокировки подсетей IP-адресов. Как правило, более 95% пользователей сервиса находятся в пределах СНГ, и блокировка какого-либо региона из США или Европы им не помешает.

После сбора информации от одной-двух таких атак и принятия соответствующих мер можно с лёгкостью переносить следующие атаки, так как почти все они похожи между собой.


3.3.2 Защита серверов от несанкционированного доступа


На части серверов информационной системы используется ОС Windows Server 2008 R2, на остальных – Windows Server 201210. Для снижения рисков несанкционированного доступа применяются следующие меры:

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

  2. порт RDP изменён на нестандартный;

  3. в брандмауэре настроен список разрешённых портов и IP-адресов, все остальные соединения блокируются.

3.3.3 Защита приложения декомпиляции не нелегального использования


Строго говоря, приложения платформы .NET не являются в полной мере компилируемыми. При компиляции код с языка программирования (C# или Visual Basic) преобразуется в так называемый IL-код, который является аналогом машинных кодов, но более высокого уровня, и выполняется он самой платформой .NET (именно поэтому приложения данной платформы не работают без установленного .NET Framework) [22].

Существуют различные декомпиляторы, которые позволяют из исполняемого файла приложения получить исходный код [23]. Хотя в клиентском приложении рассматриваемой информационной системы не содержится наиболее важных алгоритмов системы (все существенные вычисления производятся на серверах), защиту кода выполнять всё же необходимо. Для этого существует специальный класс программ – обфускаторы [24]. Они позволяют запутывать код, изменять имена переменных, чтобы терялся их смысл (часто также есть возможность использовать Unicode-символы для переименования, которые ещё больше ухудшают читаемость кода), запретить присоединение отладчика и многое другое. Ещё одна полезная функция многих обфускаторов – встраивание всех используемых библиотек в исполняемый файл. Если при этом ещё использовать и обфускацию самих библиотек, то нарушитель не сможет определить, какие именно сторонние библиотеки использовались в приложении.

Для использования в приложении выбран обфускатор SmartAssembly. Он имеет все необходимые функции.

На рисунке 6 отображёна структура обфусцированного проекта в декомпиляторе.



c:\мои документы\картинки\screenshots\12.12.2013 shot0009.png

Рисунок 6. Структура обфусцированного проекта в декомпиляторе
Можно увидеть наличие большого числа сборок, названия которых не отображаются из-за ASCII-символов, при этом в каждой сборке есть несколько методов с аналогичными названиями, а также большое количество ссылок сборок друг на друга. В нижней части можно увидеть сборку BetLinker, содержащую классы Bookmaker и BookmakerSettings – их названия специально были исключены из обфускации для демонстрации. При этом структура методов данных классов всё также запутана, что видно на следующем рисунке. На рисунке 7 приведена структура частично обфусцированного метода.

c:\мои документы\картинки\screenshots\12.12.2013 shot0010.png

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

Кроме пп. 3.3.2 и 3.3.5 защита от нелегального использования заключается в переносе всей логики авторизации на сервер. Даже если нарушитель обойдёт серверную авторизацию с помощью эмуляции ответа сервера и войдёт в программу, он получит доступ только ко второстепенным функциям (встроенный браузер, учёт), которые бесполезны при отсутствии информации об арбитражных ситуациях. Именно эту информацию сервер отправляет клиентам только при успешной авторизации на его стороне.


3.3.4. Защита базы данных от несанкционированного доступа


Получить доступ или модифицировать базу данных злоумышленник может следующими способами:

  1. через уязвимости в обработке HTTP-запросов;

  2. подбором логина и пароля для доступа к базе.

Самым известным способом получения доступа к базе данных через HTTP-запросы являются SQL-инъекции [18]. Для их предотвращения необходимо использовать не конструирование текстового запроса путём конкатенации строк, а применять метод SQLCommand.Parameters.Add() [19] – в этом случае кавычки всегда будут изолированы, и запрос к базе будет выполнен без модификации, желаемой нарушителем.

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



  1. использование для базы данных отдельного сервера, IP-адрес которого злоумышленник узнать не может;

  2. запрет доступа к порту SQL сервера со всех IP-адресов, кроме разрешённых;

  3. перенос SQL сервера на нестандартный порт;

  4. использование системы блокировки доступа при большом числе неудачных попыток авторизации.

На рассматриваемой информационной системе применены пункты 1 и 2, они являются достаточными. Пункты 3 и 4 менее надёжны, а в данной ситуации также являются избыточными.

Кроме того, клиентское приложение не связывается с сервером базы данных напрямую, а отправляет запросы через Web-сервис. В противном случае получение несанкционированного доступа к базе данных было бы упрощено.


3.3.5. Защита от подбора паролей к учётным записям пользователей


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

Тем не менее, защита от подбора пароля включена через расширение «Dynamic IP Restrictions» (см. пп. 3.3.1).


3.3.6. Защита конфиденциальных данных пользователей


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

Для противодействия несанкционированного доступа все конфиденциальные данные шифруются с использованием алгоритма AES [29]. При этом в качестве пароля для шифрования используется комбинация логина, пароля входа в учётную запись сервиса и некоторых других личных данных.


3.3.7. Защита исходного кода от утерь по техническим причинам


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

Резервные копии кодовой базы рассматриваемой информационной системы создаются ежедневно с помощью бесплатной утилиты Comodo BackUp [30]. Несмотря на свою бесплатность, она имеет множество функций и позволяет выбрать для резервного копирования конкретные папки, логические разделы, системный реестр и даже данные браузера. Местом назначения может быть другая папка, облачное хранилище, FTP-сервер, компакт-диск, сетевое устройство или адрес электронной почты. При этом поддерживается сжатие исходных данных в ZIP-архив.

Кроме кодовой базы, важно сохранять резервные копии базы данных. Так как в информационной системе используется SQL Server Express, который не имеет встроенных средств резервного копирования по расписанию, необходимо найти стороннее приложение, которое выполняло бы эти функции. Была найдена утилита SQLBackupAndFTP [31], написанная нашим соотечественником. Её функции аналогичны программе Comodo BackUp, но работает она с базой данных Microsoft SQL Server. Кроме этого, приложение имеет функцию отправки отчёта выполнения задания на электронную почту, что позволяет следить за работоспособностью резервного копирования.

3.3.8. Обеспечение бесперебойной работы серверов


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

  1. для серверов загрузки – время последнего получения данных с букмекерских контор;

  2. для серверов обработки – время последней обработки полученных данных;

  3. для координирующего сервера – работоспособность не проверяется, так как при его отключении останавливается обработка данных и срабатывает оповещение из п.2;

  4. для сервера отправки – время последней отправки данных какому-либо клиенту.

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

3.4. Выводы по главе 3


В третьей главе рассмотрена модель потенциального нарушителя, на её основе определены возможные угрозы безопасности информационной системы, описаны принятые меры для защиты от них.

4. Модернизация клиентской части. Дальнейшая поддержка системы

4.1. Развитие клиентского приложения


За 3 года проведена работа не только над сервером. Клиентское приложение также значительно доработано. В первую очередь, оно получило собственный логотип и дизайн (см. рисунки 8-19). Для создания нестандартного оформления использована библиотека DevExpress.XtraEditors [25]. Её класс XtraForm позволил заменить стандартную форму окна Windows на другую, с собственным внешним видом.

c:\c#\betlinker\images\splash2.png

Рисунок 8. Логотип приложения
Уникальный дизайн является полезным решением, помогающим составить приятное первое впечатление у пользователя, а также выделяющим клиентское приложение на фоне конкурентных сервисов.

Появилось большое число функций, значительно облегчающих пользователю работу на арбитражных ситуациях. Основные из них описаны в пп. 4.1.1-4.1.7.


4.1.1. Главное окно программы


Окно программы состоит из нескольких частей.

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

  2. Калькулятор ставок: позволяет рассчитать сумму каждой ставки. Обладает всеми необходимыми функциям: конвертация валют, округление, ввод частных сумм, перевес ставок, учёт комиссии, фиксирование сумм. Поддерживается расчёт по всем 5000 подключённым комбинациям (общее число формул для расчёта – 22).

  3. Всплывающая панель фильтра: даёт доступ к настройке всех доступных критериев фильтра (сейчас их 17).

  4. Главное меню и панель элементов: доступ к основным функциям программы.

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

На рисунке 9 приведён снимок главного окна приложения.

c:\мои документы\картинки\screenshots\11.12.2013 shot0001.png

Рисунок 9. Снимок главного окна приложения
На рисунке 10 приведён снимок панели фильтрации, появляющейся при нажатии кнопки «Фильтр» на панели элементов.

c:\мои документы\картинки\screenshots\11.12.2013 shot0002.png

Рисунок 10. Снимок панели фильтрации

4.1.2. Встроенный браузер


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

  1. автоматическая авторизация на сайтах;

  2. одновременное отображение двух или трёх окон, согласно специфике арбитражных ситуаций;

  3. встроенный калькулятор;

  4. автоматическое или ручное снятие скриншотов каждого окна.

Во время рассмотрения реализации функции изучены различные библиотеки встраивания браузера. На тот момент (2011 год) были доступны:

  1. WebKitSharp – не подошла, так как имела очень мало функций, не позволяла производить автоматизацию;

  2. WebBrowser – доступная по умолчанию библиотека встраивания Internet Explorer; применять её нежелательно и сейчас, так как запускается версия Internet Explorer, установленная в данный момент у пользователя – разные версии несовместимы между собой, могут возникать исключительные ситуации и отказ автоматизации;

  3. GeckoFX – библиотека встраивания Gecko (который лежит в основе Mozilla Firefox) [26] – при детальном рассмотрении полностью подошла, поэтому и была использована.

На рисунке 11 приведён снимок окна встроенного браузера после открытия в нём одной из доступных арбитражных ситуаций.

c:\мои документы\картинки\screenshots\01.12.2013 shot0004.png

Рисунок 11. Снимок окна встроенного браузера
Библиотека GeckoFX оперативно обновляется, её актуальная версия позволяет применять предпоследнюю версию Mozilla Firefox для встраивания [27]. GeckoFX позволяет автоматизировать действия пользователя – ввод символов в текстовое поле, выбор элемента из выпадающего списка, нажатие кнопок и т.д.

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


4.1.3. Учёт ставок


Учёт ставок – необходимый инструмент при заработке на арбитражных ситуациях. Он позволяет вести статистику сделанных ставок, помнить, как распределены средства, и подводить итоги по результатам периода.

Основные особенности учёта в приложении:



  • хранение арбитражных ситуаций, одиночных ставок, бонусов, пополнений счёта и выводов денег в букмекерских конторах;

  • контроль над балансом средств во всех игровых счетах;

  • просмотр статистики за выбранный период.

На рисунке 12 приведён снимок окна учёта ставок, в котором отображены предыдущие и текущие операции.

c:\мои документы\pictures\screenshots\17.06.2012 shot0006.jpg

Рисунок 12. Снимок окна учёта ставок
Занесение данных в учёт максимально упрощено. При нажатии кнопки «В мои вилки» в главном окне приложения или встроенном браузере автоматически вносятся все данные по операции, в открывшемся окне достаточно нажать кнопку «ОК». На рисунке 13 приведён снимок окна редактирования операции.

c:\мои документы\картинки\screenshots\11.12.2013 shot0004.png

Рисунок 13. Снимок окна редактирования операции
Все изменения по операциям производятся в окне редактирования записи. Для каждой арбитражной ситуации есть возможность добавить любое число ставок (исходов), оставить заметку, установить напоминание, записать результат и т.д.

База учёта хранится в формате SQLite [28], при этом есть встроенная функция резервного копирования по расписанию для предотвращения потери данных.


4.1.4. Сервис сравнения коэффициентов


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

На рисунке 14 приведён снимок окна сводной таблицы ставок.



c:\мои документы\картинки\screenshots\11.12.2013 shot0005.png

Рисунок 14. Снимок окна сводной таблицы ставок
Быстрое сравнение коэффициентов есть во встроенном браузере. Достаточно щелкнуть по названию букмекера и можно увидеть список других коэффициентов на данную ставку, отсортированных в порядке убывания. На рисунке 15 приведён список похожих коэффициентов, доступный во встроенном браузере.

c:\мои документы\картинки\screenshots\11.12.2013 shot0006.png

Рисунок 15. Список похожих коэффициентов

4.1.5. Поиск событий


Функция поиска событий позволяет найти нужный матч, указав название одной команды или обеих команд. При нажатии на строку в колонке «Событие» откроется окно ставок на выбранный матч (см. пп. 4.1.4).

На рисунке 16 приведён снимок окна поиска матчей после введения текста и нажатия кнопки «Поиск».



c:\мои документы\картинки\screenshots\11.12.2013 shot0008.png

Рисунок 16. Снимок окна поиска матчей


4.1.6. Модуль автоматического обновления


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

Окно проверки новой версии можно вызвать и вручную, выбрав в меню клиентского приложения пункт «Помощь – Проверить обновление». В нём отображается список всех версий в убывающем порядке с описанием основных внесённых изменений, а также номер текущей версии приложения, установленного у пользователя и номер последней версии на сайте сервиса. В случае несовпадения версий в окне обновления появляется соответствующая информация и кнопка «Обновить». При нажатии на неё приложение производит загрузку необходимых файлов, затем открывает модуль обновления, который завершает работу приложения и обновляет все файлы, после чего снова запускает приложение.

На рисунке 17 отображён снимок окна обновления, которое показывает, что текущая версия совпадает с последней версией на сайте сервиса.
c:\мои документы\картинки\screenshots\11.12.2013 shot0007.png

Рисунок 17. Снимок окна обновления
Периодически выходят критические обновления. Чтобы форсировать переход пользователей на новую версию, существует список разрешённых версий. Приложение обращается к данному списку, и в случае отсутствия своей версии в списке разрешённых блокирует все функции и предлагает обновиться.

4.1.7. Раздел предложений


Для помощи в правильном развитии сервиса создан раздел предложений, в котором пользователи добавляют новые идеи и голосуют за существующие. Предложения с наибольшим числом голосов «За» реализуются в первую очередь. Пользователи могут оставлять комментарии к конкретной идее, это помогает узнать подробнее позицию каждого человека.

На рисунке 18 отображён снимок окна предложений пользователей.



30.11.2012 shot0004.png

Рисунок 18. Снимок окна предложений пользователей
На рисунке 19 отображён снимок окна комментариев к предложению.

30.11.2012 shot0005.png

Рисунок 19. Снимок окна комментариев к предложению

4.2. Поддержка работы системы


Кроме резервного копирования и обеспечения бесперебойной работы серверов (см. пп. 3.9 и 3.10) поддержка сервиса заключается в следующем.

4.2.1. Исправление возникающих ошибок


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

  1. Через встроенный механизм отправки сообщений об ошибках, доступный в клиентском приложении. Пользователь выполняет минимальное количество действий, информация в наиболее полном виде отправляется на служебный электронный адрес. Для моментального оповещения о поступивших заявках передача сообщений настроена на IM-клиент.

  2. Через встроенный механизм обратной связи. С помощью него можно не только сообщить об ошибках, но и задать вопрос или предложить идею.

  3. Через форум сервиса. На форуме создана отдельная тема, где каждый желающий может сообщать об ошибках.

4.2.2. Решение текущих административных задач


Административные задачи включают в себя:

  1. общение с клиентами, ответы на их вопросы и предложения;

  2. своевременная публикация всех новостей, касающихся работы сервиса;

  3. работа с партнёрской программой: выплаты процентов текущим партнёрам (привлечение новых не производится, так как база клиентов уже достаточно велика);

  4. выбор главных направлений развития проекта в соответствии с пожеланиями клиентов и пп. 4.1.7.

4.3. Оценка эффективности


В таблице 5 приведено сравнение созданной системы с аналогами.
Таблица 5. Сравнение созданной системы с аналогами

Название

SureBet

AllBestBets

RebelBetting

Собственная разработка

Число букмекеров

56

34

38

111

Средний период обновления данных, сек.

100

40

30

15

Примерное число комбинаций

1000

800

300

1200

Способ доставки информации

Web-сайт

Web-сайт

Приложение

Приложение

Встроенный браузер

-

-

+

+

Встроенный учёт ставок

-

-

-

+

Сервис сравнения линий

-

-

-

+

Год запуска

2009

2012

2009

2011

Число разработчиков

4

4

8

1

Стоимость, руб./месяц

1000

800

5000

2000

4.4. Выводы по главе 4


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

Заключение


В ходе работы над проектом выполнены все поставленные задачи:

  1. спроектирована структура информационной системы;

  2. разработана серверная и клиентская часть;

  3. выбран и реализован метод лицензирования клиентского приложения;

  4. значительно оптимизирован алгоритм обработки данных;

  5. оптимизирован протокол передачи данных от сервера клиентскому приложению;

  6. выполнены мероприятия по обеспечению безопасности системы;

  7. введено множество дополнительных функций в клиентское приложение, выполнена оценка эффективности.

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

Список использованной литературы


  1. Википедия: Букмекерская вилка. URL: http://ru.wikipedia.org/wiki/Букмекерская_вилка (Дата обращения: 01.02.2014).

  2. Sports Arbitrage Guide: Sports Arbitrage Alert Services. URL: http://www.sportsarbitrageguide.com/components/alerts/ (Дата обращения: 17.12.2013).

  3. Ник Рендольф, Дэвид Гарднер, Майкл Минутилло, Крис Андерсон: Visual Studio 2010 для профессионалов. — М.: «Диалектика», 2011. — С. 1184. — ISBN 978-5-8459-1683-9.

  4. Джон Скит. C#: программирование для профессионалов, 2-е издание. — М.: «Вильямс», 2011. — 544 с. — ISBN 978-5-8459-1555-9.

  5. Рэнд Моримото, Майкл Ноэл, Омар Драуби, Росс Мистри, Крис Амарис: Microsoft Windows Server 2008 R2. Полное руководство. — М.: «Вильямс», 2011. — С. 1456. — ISBN 978-5-8459-1653-2.

  6. Дэвид Хантер, Джефф Рафтер: XML. Базовый курс. — М.: Вильямс, 2009. — 1344 с. — ISBN 978-5-8459-1533-7.

  7. Википедия: Сериализация. URL: http://ru.wikipedia.org/wiki/Сериализация (Дата обращения: 01.02.2014).

  8. Википедия: JSON. URL: http://ru.wikipedia.org/wiki/JSON (Дата обращения: 17.12.2013).

  9. Microsoft Developer Network: XML Serialization in the .NET Framework. URL: http://msdn.microsoft.com/en-us/library/ms950721.aspx (Дата обращения: 07.06.2011).

  10. Википедия: gzip. URL: http://ru.wikipedia.org/wiki/Gzip (Дата обращения: 17.12.2013).

  11. Википедия: Наибольшая общая подстрока. URL: http://ru.wikipedia.org/wiki/Наибольшая_общая_подстрока (Дата обращения: 25.03.2011).

  12. Джеф Просиз: Программирование для Microsoft .NET. — М.: Русская редакция, 2003. — С. 704. — ISBN 5-7502-0217-8.

  13. Роберт Э. Уолтерс, Майкл Коулс: SQL Server 2008: ускоренный курс для профессионалов. — М.: «Вильямс», 2008. — С. 768. — ISBN 978-5-8459-1481-1.

  14. Р. Стенли. Перечислительная комбинаторика. — М.: Мир, 1990.

  15. Microsoft Developer Network: System.Collections.Concurrent - пространство имен. URL: http://msdn.microsoft.com/ru-ru/library/system.collections.concurrent(v=vs.100).aspx (Дата обращения: 24.08.2012).

  16. Microsoft Developer Network: Synchronous Server Socket Example. URL: http://msdn.microsoft.com/en-us/library/6y0e13d3(v=vs.100).aspx (Дата обращения: 17.12.2013).

  17. Бойченко А.В., Кондратьев В.К., Филинов Е.Н. Основы открытых информационных систем. 2-е издание, переработанное и дополненное. Под ред. Кондратьева В.К. //Издательский центр АНО «ЕОАИ». – М.:, 2004. – 128 с.

  18. Википедия: Внедрение SQL-кода. URL: http://ru.wikipedia.org/wiki/Внедрение_SQL-кода (Дата обращения: 17.12.2013).

  19. StackOverflow: C# - Different ways of passing sqlCommand parameters. URL: http://stackoverflow.com/questions/4624811/different-ways-of-passing-sqlcommand-parameters (Дата обращения: 17.12.2013).

  20. The Official Microsoft IIS Site: Dynamic IP Restrictions. URL: http://www.iis.net/downloads/microsoft/dynamic-ip-restrictions (Дата обращения: 17.12.2013).

  21. Хабрахабр: Обзор CDN-сервиса CloudFlare. URL: http://habrahabr.ru/post/125823/ (Дата обращения: 17.12.2013).

  22. Википедия: Common Interface Language. URL: http://ru.wikipedia.org/wiki/Common_Intermediate_Language (Дата обращения: 17.12.2013).

  23. Википедия: Декомпилятор. URL: http://ru.wikipedia.org/wiki/Декомпилятор (Дата обращения: 17.12.2013).

  24. Хабрахабр: Обзор обфускаторов для .NET. URL: http://habrahabr.ru/post/97062/ (Дата обращения: 17.12.2013).

  25. DevExpress: WinForms Controls. URL: https://www.devexpress.com/Products/NET/Controls/WinForms/ (Дата обращения: 17.12.2013).

  26. Википедия: XULRunner. URL: http://ru.wikipedia.org/wiki/XULRunner (Дата обращения: 17.12.2013).

  27. Bitbucket: geckofx. URL: https://bitbucket.org/geckofx (Дата обращения: 18.12.2013).

  28. Хабрахабр: SQLite – замечательная встраиваемая БД. URL: http://habrahabr.ru/post/149356/ (Дата обращения: 18.12.2013).

  29. Баричев С.Г., Гончаров В.В., Серов Р.Е. 2.4.2. Стандарт AES. Алгоритм Rijdael. — М.: Горячая линия — Телеком, 2002. — С. 30-35. — ISBN 593517-075-2.

  30. Comodo Backup: Cloud Online Storage | Free Online Backup Software from Comodo. URL: http://backup.comodo.com/ (Дата обращения: 02.02.2014).

  31. Sql Backup And FTP: Free SQL backup software for MS SQL Server 2008, 2012 and 2005 (Express) databases. URL: http://sqlbackupandftp.com/ (Дата обращения: 02.02.2014).



Приложение


Структуры данных, используемые для передачи между серверами


Название структуры

Поле

Тип

Примечание

Ставка

Название

Строковое

Для однозначного определения ставки

Коэффициент

Числовое




Максимальная сумма ставки

Числовое

Доступно не у всех букмекеров

Прямая ссылка на сайте

Строковое

Доступно не у всех букмекеров

Набор ставок

Список ставок

Множество объектов типа «Ставка»




Прямая ссылка на сайте

Строковое

Доступно не у всех букмекеров

Матч

Название первой команды

Строковое




Название второй команды

Строковое




Перевод названия первой команды

Строковое




Перевод названия второй команды

Строковое




Упрощённое название первой команды

Строковое

Для поиска такого же матча у других букмекеров

Упрощённое название второй команды

Строковое

Для поиска такого же матча у других букмекеров

Начало матча

Дата/время




Прямая ссылка на сайте

Строковое

Доступно не у всех букмекеров

Ставки на матч

Объект типа «Набор ставок»




Ставки на первый тайм/сет/период

Объект типа «Набор ставок»




Ставки на второй тайм/сет/период

Объект типа «Набор ставок»




Ставки на третий сет/период

Объект типа «Набор ставок»




Ставки на угловые

Объект типа «Набор ставок»




Ставки на жёлтые карточки

Объект типа «Набор ставок»




Ставки на угловые первого тайма

Объект типа «Набор ставок»




Ставки на угловые второго тайма

Объект типа «Набор ставок»




Ставки на жёлтые карточки первого тайма

Объект типа «Набор ставок»




Ставки на жёлтые карточки второго тайма

Объект типа «Набор ставок»




Ставки на первую четверть

Объект типа «Набор ставок»




Ставки на вторую четверть

Объект типа «Набор ставок»




Ставки на третью четверть

Объект типа «Набор ставок»




Ставки на четвёртую четверть

Объект типа «Набор ставок»




Чемпионат

Название

Строковое




Перевод названия

Строковое




Упрощённое название

Строковое




Список матчей

Множество объектов типа «Матч»




Букмекер

Адрес

Строковое




Название

Строковое




Список чемпионатов

Множество объектов типа «Чемпионат»







1Например, при добавлении или изменении поля в используемой структуре данных ничего не придётся переписывать.

2 При использовании сети 100 Мбит/с.

3 Например, датский футбольный клуб «Midtjylland» переводится как «Мидтъюлланн», хотя по английским лексическим нормам это было бы что-то вроде «Мидтджиллэнд».

4 .NET Framework версии 3.5 имеет объём около 300 МБ, что довольно много для загрузки из интернета, особенно учитывая тот факт, что размер самого клиентского приложения не превышал 1 МБ.

5 Используя приведённую формулу, можно посчитать, сколько времени могла занимать обработка данных без проведения оптимизаций. Каждый букмекер в среднем даёт ставки по 200 матчам, поэтому:

  1. итераций, то есть 171100 итераций в секунду;

  2. итераций.

Примерное время работы составило бы 350 секунд, таким образом оптимизация позволила ускорить обработку данных в 175 раз.

6Подразумевается, что был изменён коэффициент хотя бы у одной ставки матча.

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

8 Это утверждение подтверждено опытным путём.

9 Сначала был использован произвольный порт, но обнаружилась проблема: если на компьютере пользователя работает Firewall, то, как правило, разрешён доступ только к стандартным портам (23, 80, 443 и т.д.), что приводило к неудобствам – пользователям приходилось добавлять исключения, а некоторые вообще не понимали суть проблемы.

10 Выбор разных версий обусловлен только тем, что компания-собственник серверов (у которой производится аренда) предоставляет их с операционной системой, актуальной на момент взятия в аренду.
скачать файл



Смотрите также:
Разработка защищённой распределённой информационной системы «инструменты для заработка на ставках»
437.93kb.
«Московская городская детская музыкальная школа имени И. О. Дунаевского»
1318.39kb.
«Оркестровые духовые и ударные инструменты» (флейта, гобой, кларнет, фагот, труба, валторна, тромбон, туба, ударные инструменты) для абитуриентов 2014 года
47.96kb.
1. Понятие информационной системы
26.61kb.
Закон Ростовской области от 3 марта 2014 г. N 110-зс "О региональной информационной системе "Геоинформационная система Ростовской области" Принят Законодательным Собранием 20 февраля 2014 г
117.79kb.
Нп «орловское объединение участников президентской программы подготовки управленческих кадров» Конференция «маркетинг и продажи-2013» практические инструменты для малого и среднего бизнеса
95.52kb.
Разработка технических и программных средств системы предсказания прорывов корочки сляба
740.26kb.
«Разработка и исследование прототипа интеллектуальной системы для согласованного адаптивного планирования и связанного изменения планов движения поездов для минимизации отклонения высокоскоростных поездов класса "Сапсан" от графика движения под влиянием непредвиденных
68.4kb.
А. В. Шлянников Разработка клиент-серверной системы для курьерской службы. Технологии : Android, Swing, jboss as, rmi, ejb, Google Maps api. Искандер Самерханов, Рамис Ямилов (991и) курсовая
11.88kb.
Отчет по результатам диагностики системы управления персоналом ОАО "xxx" Москва 2003 год
1162.71kb.
Книга об активности, но о меньшей активности
1832.16kb.
Анютины глазки
555.2kb.