#networking #browser #synchronization #connection
#сеть #браузер #синхронизация #подключение
Вопрос:
Извините, если это глупый вопрос, который уже задавался, но я даже не знаю, какие термины лучше всего искать.
У меня ситуация, когда облачное приложение доставляет SPA (одностраничное приложение) в клиентский веб-браузер. Несколько клиентов будут подключаться одновременно и все будут работать в одной сети. Примером может служить приложение, которое бизнес использует для совместной работы — все в одном физическом пространстве (все в одной сети).
Проблема заключается в том, что подключение к Интернету может быть прерывистым. Я знаю, что могу сохранить изменения клиента локально, а затем отправить их все на сервер после восстановления соединения. Проблема, однако, заключается в том, что некоторым клиентам (системам отображения) потребуется отображать актуальные данные от других клиентов (мобильных систем ввода). Если интернет отключится на минуту или две, это будет неприемлемо.
Мое текущее мышление заключается в том, что локальной сети потребуется какой-то «тонкий сервер», к которому будут подключаться все клиенты. Затем этот тонкий сервер будет работать как прокси для основного облачного сервера. Если интернет выйдет из строя, то ThinServer возьмет на себя работу по синхронизации данных. Поскольку все клиенты будут полными СПА-центрами, единственное, что перемещается, — это данные, поэтому thinserverу действительно нужно было бы просто синхронизировать информацию о БД (вероятно, ему не нужно было бы размещать полный СПА-центр — хотя, это было бы неплохо).
Однако для большинства компаний установка полноценного выделенного сервера, очевидно, является большим препятствием.
Итак, вопрос в том, существует ли какая-либо технология, которая позволила бы веб-странице выступать в качестве веб-сервера? Можно ли поручить бизнесу перейти thinserver.coolapp.com в браузер на любом из своих компьютеров? Затем на этой «веб-странице» будет указано: «Все клиенты в этой сети должны подключиться к 192.168.1.74: 2000» (это будет IP: порт компьютера, на котором запущена эта страница). Затем все клиенты будут подключаться к этому новому «серверу», и этот сервер будет действовать как координатор данных, если Интернет когда-либо отключится.
Другими словами, мне действительно не нравится идея сложной настройки сервера. Достаточно простого URL-адреса для запуска службы.
Я полагаю, что единственным вариантом может быть двоичная программа, которую необходимо будет установить? Это не идеальное решение, но, возможно, единственное? Если да, существуют ли какие-либо их программы, которые являются веб-серверами с одним щелчком мыши? Я пробовал MAMP, LAMP и т. Д., Но все они предназначены для разработчика. Любые другие, которые более оптимизированы?
Спасибо за любые идеи!
Комментарии:
1. Это прекрасный подход, который вы использовали для предоставления подобной услуги. Я полагаю, вы нашли свое решение? Насколько хорошо это работало?
Ответ №1:
Есть несколько основных способов, которыми вы можете подойти к этому. Первый — разместить сервер в браузере, как вы предлагаете. Некоторые примеры проектов:
Другой способ — использовать одноранговую связь WebRTC, чтобы браузеры могли обмениваться информацией друг с другом (вы могли бы предоставить им общую дату или иметь один акт в качестве «мастера» и т. Д., Углубляя не ту архитектуру, которую вы хотели). Вероятно, он не будет сильно отличаться под кожей, но дизайн вашего приложения может лучше подходить для более одноранговой модели или более клиент-серверной модели, в зависимости от того, что вам нужно. Пример проекта «одноранговый узел»:
Я лично не использовал ничего из вышеперечисленного, но я бы сказал, что, используя аналогичные механизмы расширения браузера в прошлом, вам нужно проверить требования браузера, прежде чем вы решите, могут ли они делать то, что вы хотите. Верхний из них основан на Chrome (я полагаю), а второй — Firefox. Одноранговый содержит список совместимых функций браузера, но фактически также основан на Firefox и Chrome (см. Таблицу по ссылке). Если вы находитесь в среде, где вы можете диктовать тип браузера и плагины и т.д., то это может быть хорошо для вас.
Концепция, безусловно, очень интересная (одноранговые веб-серверы), и это здорово, если у вас есть время для ее изучения. Однако, если у вас есть неотложные бизнес-требования, может оказаться, что простой подход, основанный на сервере на сайте, на самом деле может быть более надежным, поддерживать более широкий выбор браузеров и на самом деле быть проще в обслуживании (поскольку требуемые навыки довольно широко доступны).
Кстати, я должен был сказать — «WebRTC», вероятно, является хорошим поисковым термином для вас, в ответ на первую строку вашего вопроса.
Комментарии:
1. Спасибо! Это лучшая информация, которую я понял, была доступна. Я слышал о RTC, но думал, что сейчас об этом только читают видео, и похоже, что одноранговые данные тоже отлично подходят для этого. Но вы правы в том, что установка сервера на данный момент может быть проще. Я продолжу исследование. Большое вам спасибо за ваш вклад!
2. Удачи! Возможно, вы можете обновить здесь в комментарии или другом ответе, если найдете надежное одноранговое решение, которое вас устраивает.
3. Я буду. Пока WebRTC кажется лучшим вариантом, поскольку я могу «заставить» пользователей использовать определенные компьютеры и браузеры. Еще раз спасибо.
4. Вы также можете заставить приложение работать в автономном режиме с помощью service worker , который действует как прокси-сервер в браузере.
Ответ №2:
httprelay.io v.s. WebRTC
Плюсы:
- Простой в использовании
- Быстро
- Поддерживается всеми браузерами и HTTP-клиентами
- Может использоваться с нестабильной сетью
- С открытым исходным кодом и кросс-платформенный
Минусы:
- Необходимо запустить экземпляр сервера
- Потоковая передача данных не поддерживается (пока)
Комментарии:
1. Спасибо за это! Я обдумывал различные способы реализации P2P без серверов bitttorrent-tracker, и это, безусловно, альтернатива, которую я искал!