Синхронізація зі знанням того, що є на пристрої

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

Ідея підходу наступна. Сервер зберігає у себе (в окремій таблиці " stored_item_list ") інформацію про те, які записи є на пристрої. Це список пар "device_id – lot_id - updated". У цій таблиці зберігаються всі списки пар "id - updated" інформації для кожного device_id.

Інформацію про наявні на пристрої записи (список пар "id - updated") пристрій відсилає сервера разом із запитом на синхронізацію. При запиті сервер перевіряє те, які страви мають бути на пристрої і які є зараз. Після цього на пристрій відсилається різниця.

Для того щоб сервер визначав які записи повинні бути на пристрої сервер робить запит, який поверне йому список пар "id - updated" всіх записів. На схемі це робить "WhatMustBeOnDeviceMethod ()" метод.

Для того щоб сервер визначив які вже записи є на пристрої він робить запит в таблицю "stored_item_list" по цьому пристрою і отримує список пар "id - updated".

Аналізуючи ці два списки, сервер вирішує, що слід послати на пристрій, а що - видалити. На схемі це "delta_item_list".

Для того щоб сервер визначив які вже записи є на пристрої при синхронізації у запиті до сервера додається новий параметр "items", який містить список id записів, які були надіслані на пристрій у минулій синхронізації ("device_last_stored_item_list").

При відсиланні у запиту до серверу параметру items, що містить список id записів необхідно надсилати лише ті id, що були в момент останньої синхронізації оскільки витрати трафіку будуть дуже великі. У переважній кількості синхронізацій параметр "items" буде порожньою. Сервер повинен постійно оновлювати у себе "stored_item_list" даними, які прийшли з пристрою в параметрі "items".

Слід реалізувати механізм очищення серверних даних в stored_item_list. Оскільки, після переустановлення додатку на пристрої сервер буде вважати, що на пристрої все ще актуальні дані. Тому необхідно при встановленні додатку на пристрій він повинен проінформувати сервер щоб він очистив stored_item_list по цьому пристрою. Для реалізації цього використовується додатковий параметр “clearCache” = 1.

Рис. 3.12. Схема синхронізації даних за четвертим методом

Таблиця 3.9

Тестування роботи четвертого методу

Запит, №	Кількість переданого трафіку(байт)	Час виконання операції на сервері(мс)	Час виконання операції на пристрої(мс)	Загальний час виконання операції(мс)
	277 611
	30 220
	28 930
	30 041
	29 715

Рис. 3.13. Кількість переданих байт інформації при кожному запиті

Рис. 3.14. Часова діаграма початку і завершення синхронізації

Загальна кількість переданих байт за 5 запитів дорівнює 396517.

Застосування даного методу є кращим тому, що дані синхронізуються не кожні 10 секунд, а кожні 10 секунд після завершення попередньої синхронізації. Це забезпечує, по-перше, гарантію створення лише одного потоку для синхронізації, що буде виконуватись на максимальній швидкості передачі інформації. По-друге, під час першої синхронізації спочатку передаватиметься уся необхідна інформація для роботи.

Переваги:

- дані синхронізуються максимально швидко, не залежно від характеристик пристрою

- можливість введення додаткових умов для обмеження інформації, що повинна бути на пристрої

- можливість видалення даних на пристрої за необхідності

Недоліки:

- високе навантаження на пристрій при першій синхронізації

- збільшення об’єму БД за рахунок введення додаткових таблиць

- при побудові складних мобільних додатків значно збільшується складність побудови серверного додатку для коректної роботи

Область застосування:

- при синхронізації даних, які повинні бути передані з максимальною швидкістю

- при необхідності видалення застарілих, або даних, які не повинні бути на пристрої

- при необхідності введення додаткових обмежень синхронізації конкретних даних для конкретного пристрою

Дата добавления: 2015-12-07