Разработать систему облачного хранения данных


НазваниеРазработать систему облачного хранения данных
страница1/9
ТипРеферат
  1   2   3   4   5   6   7   8   9




Задание

Разработать систему облачного хранения данных

Аннотация

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

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

Содержание


Задание 2

Аннотация 3

Введение 5

1.Техническое задание 6

2.Анализ технического задания 8

3.Разработка системы на структурном уровне 14

1.Выбор протокола. 14

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

4.Разработка программных средств 27

1.Сервер. 28

2.Клиент. 41

5.Разработка методик тестирования 53

1.Проверка работоспособности сервера. 53

2.Проверка работоспособности клиента. 66

Заключение 80

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

Приложение А 82

Приложение Б 99


Введение

В последние годы информационные технологии развиваются в геометрической прогрессии. Всего лет десять-пятнадцать назад документы набирались на компьютере, единственном на предприятии, печатались и складировались в стопках архивов. Семь лет назад каждый второй документ на предприятиях разрабатывался и хранился в электронном виде на жестких дисках или CD, а 10,32Мб памяти на телефоне хватало с запасом. Теперь же на мобильных устройствах не хватает и 32Гб памяти, а вся документация предприятия имеет несколько копий, которые в электронном виде хранятся на разных серверах, иногда даже в разных точках страны.

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

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

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


  1. Техническое задание




    1. Наименование разработки

Система облачного хранения файлов.

    1. Основание для выполнения работы

Данная работа выполняется на основании приказа на выполнение выпускной квалификационной работы.

    1. Цель разработки

Цель – разработка системы.

    1. Область применения разработки

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

    1. Функциональные требования

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

Часть системы на удаленной машине обязана:

    • хранить файлы;

    • принимать входящие файлы с локальной машины;

    • передавать имеющиеся файлы на локальную машину;

    • обеспечивать защиту файлов от несанкционированного доступа

    • Часть системы на локальной машине обязана:

    • принимать входящие файлы с удаленной машины;

    • передавать имеющиеся файлы на удаленную машину.

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

Оборудование удаленной машины должно быть сертифицировано для работы с ОС Microsoft Windows. Оборудование локальной машины должно быть сертифицировано для работы с мобильной ОС Android.

    1. Требования к программному обеспечению

Как платформу для запуска части системы на удаленной машине предполагается использовать операционную систему Microsoft Windows XP или выше. На локальной машине предполагается использование ОС Android 3.0 или выше как платформу для запуска приложения.

    1. Требования по надежности

Система должна:

  • функционировать без каких-либо посторонних вмешательств в исходный код компонент;

  • не нарушать стабильность работы платформы запуска, а также сторонних процессов систем.

    1. Требования по эргономике и технической эстетике

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

    1. Требования по эксплуатации, удобству технического обслуживания, ремонта и хранения

Система распространяется в соответствии с лицензией freeware и пользователь сам несёт ответственность за нанесённый ущерб, если система эксплуатировалась вне правил эксплуатации.

    1. Требования по стандартизации и унификации

Система разрабатывается на языках C# и Java, с учетом стандартов разработки и RFC.


  1. Анализ технического задания

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

Часть системы на удаленной машине обязана:

  • хранить файлы;

  • принимать входящие файлы с локальной машины;

  • передавать имеющиеся файлы на локальную машину;

  • обеспечивать защиту файлов от несанкционированного доступа

Часть системы на локальной машине обязана:

  • принимать входящие файлы с удаленной машины;

  • передавать имеющиеся файлы на удаленную машину.

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

«Общение» между серверной и клиентской частью происходит при помощи запросов и ответов, как и в большинстве клиент-серверных систем. Можно предположить, что клиент и сервер взаимодействуют через глобальную сеть Интернет, а значит используют определенный протокол для связи. Таковым протоколом может являться один из сетевых протоколов прикладного уровня(HTTP, HTTPS, FTP, Telnet).

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

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

Учитывая предыдущее обстоятельство, функции модуля взаимодействия с клиентом помимо передачи и приема файлов пополняться и защитой файлов от несанкционированного доступа. Тогда этот модуль можно представить в виде приложения, постоянно запущенного на удаленной машине. Приложение должно иметь возможность использовать подключение к Сети для приема и передачи данных, к тому же стоит позаботиться и о записях активности приложения в журнал. Защиту файлов от несанкционированного доступа можно выполнить как внутри самого модуля, так и возложить эту обязанность на протокол. В первом случае можно использовать какой-либо идентификатор клиентской части, будь то номер аппаратуры, либо встроенный номер экземпляра приложения, задающийся программно, либо использовать «ключ», поставляемый отдельно от программы. Гораздо проще использовать второй вариант и возложить функции защиты на протокол. При этом протоколы могут использовать простейшую авторизацию(как, например FTP), что упрощает задачу. Стоит отметить, что в отличии от клиентской части, модуль взаимодействия с клиентом не обязательно должен иметь полноценный графический интерфейс.

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

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

Таблица 1.

Задача

Метод решения

Взаимодействие серверной и клиентской части, включая прием и передачу файлов

Сетевой протокол прикладного уровня

Хранение файлов

Машина с установленной ОС и возможностью хранения файлов

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

Механизм, встроенный в используемый протокол

Разработка модуля взаимодействия с клиентом(модуля сервера)

Выполнение в виде приложения на удаленной машине

Разработка модуля клиента

Выполнение в виде приложения на локальной машине

Рисунок 1 отражает общее представление о работе системы.



Рисунок 1.

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

Рисунок 2 показывает разделение системы на уровни реализации.



Рисунок 2.

Алгоритм взаимодействия Пользователь – Система – Результат можно представить следующим образом(Рисунок 3)



Рисунок 3.

  • Пользователь вызывает клиентскую часть системы и вводит необходимые данные.

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

  • На удаленной машине серверная часть обрабатывает полученные данные. При этом обращается к средствам операционной системы на машине. Формирует результат и при помощи ОС на базе тех.средств отправляет его клиентской части.

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

Таким образом необходимо программно реализовать модуль сервера и модуль клиента. Предварительно следует составить примерный алгоритм работы модулей.

Разработка алгоритма модуля сервера.

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



Рисунок 4.

Модуль клиента также должен принимать и отправлять данные, однако запуск и завершение инициируются пользователем.

Рисунок 5 показывает алгоритм работы модуля клиента



Рисунок 5.

При этом последовательность – «Принятие данных – Отправка данных» в модуле сервера не является единственным решением. Точная последовательность будет определена уже при выборе протокола передачи.


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

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

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

    1. Выбор протокола.

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

  • установление соединения;

  • передача данных, конкретнее - файлов;

  • защита от несанкционированного доступа.

Таким образом, из всего многообразия протоколов можно выделить три, наиболее подходящих для решения описанных задач: FTP, HTTP, SMB. Причем два из них имеют дополненную реализацию с возможностью шифрования – FTPS и HTTPS, а в SMB встроенная шифрация.

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

Для грамотного выбора стоит рассмотреть каждый протокол в отдельности.

      1. HTTP.

HyperText Transfer Protocol – протокол передачи гипертекстовых документов. В современных реализациях есть возможность передавать данные любого типа. HTTP используется в глобальной Сети для получения информации с веб-сайтов. Для идентификации ресурсов HTTP использует глобальные URI. При стандартной схеме запрос-ответ можно указать способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и прочее. Имеется также подробная спецификация в RFC 1945 и RFC 2616.

Основной особенностью протокола является то, что он не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами. Например, Cookies на стороне клиента или «Сессии» на стороне сервера. Т.е. браузер(сторона клиента в данном контексте), посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов

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

      1. SMB.

Этот протокол предоставляет клиентским приложениям простой способ для чтения и записи файлов, а также способ запроса служб у серверных программ в различных типах сетевого окружения. Основанный также на технологии «клиент-сервер» имеет важное дополнение - когда клиент посылает в качестве запроса оппортунистические блокировки, то сервер вынужден отпустить уже предоставленную блокировку, так как другой клиент запросил открытие файла в режиме, несовместимом с предоставленной блокировкой. В типовой же модели блокировка не снимается. Конкретной спецификации для SMB нет, однако есть стандарты протокола для сервиса NetBIOS при использовании транспорта TCP/UDP. Эти стандарты описаны в RFC 1001(Концепции и методы) и RFC 1002(Подробные спецификации). В них также указано, что SMB может работать непосредственно поверх TCP, используя 445 порт, а также используя NetBIOS API, который занимает порты 137 и 139.

Серверы SMB предоставляют файловые системы и другие ресурсы (принтеры, почтовые сегменты, именованные каналы и т.д.) для общего доступа в сети. Клиенты соединяются с сервером, используя протоколы TCP/IP (а, точнее, NetBIOS через TCP/IP). После того, как соединение установлено, клиенты могут посылать команды серверу, который дает им доступ к ресурсам, позволяет открывать, читать файлы, писать в файлы и прочее.

Первый вариант протокола поддерживал основные операции работы с ФС:

  • присоединение к файловым и принтерным ресурсам и отсоединение от них

  • открытие и закрытие файлов

  • открытие и закрытие принтерных файлов

  • чтение и запись файлов

  • создание и удаление файлов и директорий

  • поиск директорий

  • получение и установление атрибутов файла

  • блокировка и разблокировка файлов

Однако для реализации системы можно обойтись и меньшим количеством операций. Но протокол SMB включает в себя главную возможность – механизм защиты файлов. Более того, он представлен на двух уровнях: user-level (пользовательский уровень) и share-level (уровень совместно используемого ресурса).

Аутентификация на уровне user-level предполагает, что клиент должен иметь имя пользователя и пароль. Если аутентификация прошла успешно, клиент имеет доступ ко всем доступным ресурсам сервера, кроме тех, что с share-level защитой. User-level защита дает возможность системным администраторам конкретно указывать, какие пользователи и группы пользователей имеют доступ к определённым данным.

Аутентификация на уровне share-level предполагает, что доступ к ресурсу контролируется паролем, установленным конкретно на этот ресурс. В отличие от user-level, этот уровень защиты не требует имя пользователя для аутентификации и не устанавливается никакая уникальность текущего пользователя.

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

      1. FTP.

File Transfer Protocol – стандартный протокол, предназначенный для передачи файлов по сети. Его часто используют для загрузки документов с частного устройства на открытые сервера. Протокол определен в RFC 959, но некоторые команды, например LIST, не имеют конкретной реализации. Это дает определенную свободу действий при создании системы на этом протоколе.

Особенностью FTP является использование множественного подключение. Т.е. один канал является управляющим, через который поступают команды серверу и возвращаются его ответы (по стандартам это 21 порт), а через остальные происходит передача данных, при этом выделяется по одному каналу на каждую передачу. Поэтому в рамках одной сессии по протоколу FTP можно передавать одновременно несколько файлов в обоих направлениях. Для каждого канала данных открывается свой TCP порт, номер которого выбирается либо сервером, либо клиентом, в зависимости от режима передачи. Кроме того, протокол FTP имеет двоичный режим передачи, что сокращает накладные расходы трафика и уменьшает время обмена данными при передаче больших файлов.

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

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

Таблица 2.

Свойство

HTTP

SMB

FTP

Основан на сессиях работы

Нет

Да

Да

Встроена аутентификация пользователей

Нет

Да

Да

Предусмотрен для передачи

Небольших текстовых файлов

Больших двоичных файлов

Больших двоичных файлов

Модель соединения

Одиночное подключение

Одиночное или двойное подключение

Множественное подключение

В основном приспособлен для приёма/передачи

Приёма

Приёма и передачи

Приёма и передачи

Поддерживает текстовый и двоичный режимы передачи

Нет

Нет

Да

Поддерживает указание типов передаваемых данных (MIME заголовки)

Да

Нет

Нет

Поддерживает операции над файловой системой (mkdir, rm, rename, и т. д.)

Нет

Да

Да

Учитывая данные таблицы, можно заметить, что HTTP явно проигрывает в функционале для использования в проектируемой системе. Что касается SMB и FTP, то основным фактором выбора является простота реализации. Необходимо также учесть, что для SMB нет конкретной спецификации, в отличии от FTP. Это обстоятельство позволяет создать стандартизированный программный продукт, подходящий для использования с любыми другими стандартизированными продуктами. Таким образом протоколом передачи в системе будет являться протокол FTP.

  1   2   3   4   5   6   7   8   9

Похожие:

Разработать систему облачного хранения данных iconРасшифровка -1-2-3
Техническое задание на услуги по предоставлению технологической площадки цод, обеспечивающей предоставление сервисапредоставления...

Разработать систему облачного хранения данных iconЛабораторная работа №1: Создание баз данных
В этой утилите можно выполнить типовые задачи обслуживания баз данных, такие как резервирование и восстановление. Здесь можно настраивать...

Разработать систему облачного хранения данных iconМетодические указания для выполнения лабораторных работ и «Базы данных»
Лабораторная работа №1 «Организация хранения данных в субд ms access»

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с использованием o
...

Разработать систему облачного хранения данных iconИнструкция по пакетной загрузке данных пациентов из мис в систему ведения иэмк назначение
Данная операция выполняется разово для передачи в иэмк данных о ранее зарегистрированных пациентах в мис

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИнструкция по подготовке респондентом статистической отчетности с...
...

Разработать систему облачного хранения данных iconИсследование предметной области 49
Описываются процесс разработки интерфейса пользователя под 32-разрядные операционные системы Windows’95 и Windows nt workstation....

Разработать систему облачного хранения данных iconИнструкция ответственного за систему защиты информации Дневник ру
Настоящая Инструкция разработана в соответствии с требованиями законодательства Российской Федерации в сфере защиты персональных...

Разработать систему облачного хранения данных iconЛитература: Дейт К. Введение в системы баз данных, 8-е издание. Вильямс, 2006
Субд; 3 оптимального доступа к данным с использованием субд. 4 нереляционная форма хранения данных. 5 Современные технологии доступа...

Разработать систему облачного хранения данных iconИнструкция по работе с программой ввода, хранения и обработки эпидемиологической...
Автоматизированная информационная система по мониторингу за вирусными гепатитами (аис вирусные гепатиты) предназначена для ввода...

Разработать систему облачного хранения данных iconТехническое задание на модернизацию вакуумной установки 7871-8070. Заместитель Главного инженера
С целью модернизации вакуумной установки 7871-8070 необходимо разработать кд на вакуумную установку и изготовить систему, которая,...


Руководство, инструкция по применению




При копировании материала укажите ссылку © 2018
контакты
rykovodstvo.ru
Поиск