Проверете от сървъра дали устройството с Android е онлайн

tl;dr Как да разберете от сървър дали устройството с Android е онлайн или не в даден момент?

Имам приложение, което се нуждае от интернет връзка по всяко време, за да прави резервации. Потребителят може също да направи резервации самостоятелно, от уебсайт.

Въпреки това, ако интернет връзката на устройство с Android изчезне (ръбов случай) - все пак бих искал това устройство да продължи да работи офлайн (и да прави резервации локално, офлайн), докато уебсайтът ще спре да приема резервации - защото устройството с Android вече не е свързано с интернет и може да възникнат всякакви грешки при синхронизирането.

С други думи, офлайн резервациите на Android устройство имат предимство пред резервациите на уебсайтове.

Така че след като интернет връзката бъде възстановена на устройство, уебсайтът ще продължи да работи правилно.

Предложено решение

Мислех за някакво решение, което може да включва изпращане на натискане от сървър към устройство и изчакване на отговор (HTTP повикване до някаква крайна точка) в някакъв разумен период от време. Ако отговорът не се върне - устройството е офлайн, в противен случай е онлайн. Някакви други, по-стабилни предложения?


person svenkapudija    schedule 20.09.2013    source източник
comment
Не би ли било много по-добре за вас да излезете с по-стабилен протокол и да избегнете всички видове грешки при синхронизиране на първо място?   -  person CommonsWare    schedule 21.09.2013
comment
Как бих могъл да направя това? Изискванията са потребителят да може да направи резервация онлайн (уебсайт) и оператор да може да го направи от устройство (офлайн или онлайн). И потребителят, и операторът трябва да знаят (преди да направят действителна резервация) кои слотове са свободни/отворени. Би било лесно да се изисква, ако няма интернет връзка на устройството, резервациите да не са възможни - обаче това не може да бъде така.   -  person svenkapudija    schedule 21.09.2013
comment
Как бих могъл да направя това? -- хм, чрез програмиране. В края на краищата трябва да направите това така или иначе. Устройствата се включват и офлайн много често, а уеб браузърите не са имунизирани срещу проблеми. Според вашия план, ако можете да определите, че устройството е онлайн в момент T, тогава очаквате целият свят да спре, за да сте сигурни, че устройството ще остане онлайн (и уеб браузърът няма да има проблеми) до време T+X, когато цялата работа е завършена. Това е просто нереалистично. Ако това означава, че е необходима промяна на вашите изисквания, така да бъде.   -  person CommonsWare    schedule 21.09.2013
comment
Сега е свършена много работа по алгоритмите за синхронизация. Един подход е да се каже, че резервацията не е напълно реална, докато и двете страни не са си свършили работата. Това обикновено изисква ресурсите (напр. слотове) да бъдат поставени в чакащо състояние, докато транзакцията е в ход, така че никой друг не може да превземе тези ресурси, докато това се случва. Това обикновено включва и някакъв вид таймаут, така че изоставена транзакция в крайна сметка се изчиства и ресурсите се преместват обратно от чакащи в свободни състояния.   -  person CommonsWare    schedule 21.09.2013


Отговори (1)


@szx: също се обработва от пейджинг. Не само обаче. x86 има две ограничения за защита в защитен режим за достъп до паметта: селектори и страници. Пейджингът обаче няма ограничения за сигурност за данните, така че те не могат да използват едни и същи селектори, или ще можете да изпълните самопроменящ се код, без да прескачате през обръчите. Също така бихте могли да създадете съответно грешки, когато случайно прескочите в данни. Което не можете (по подразбиране).
person Maxim Shoustin    schedule 20.09.2013
comment
Проблемът с този подход е, че потребителят може да стигне до уебсайт и да направи резервация между обажданията на агент (онлайн -› офлайн). Така че времевата линия ще бъде: устройството е онлайн -› уведомява сървъра -› устройството е офлайн -› резервацията е направена на устройството в офлайн режим -› потребителят прави резервация онлайн. Може да възникне потенциален сблъсък. - person svenkapudija; 21.09.2013
comment
В никакъв случай, създайте политика за сървър (някаква работа на cron като услуга), която ако клиентът не ви е уведомил, да речем, в продължение на 1 седмица - актуализирайте DB за клиента като зомби. Сигурен съм, че записвате в базата данни всички клиенти, изискващи времеви печат - person Maxim Shoustin; 21.09.2013