Ip workers что это

Некоторые тонкости использования Service Workers

Предисловие

Сервис-воркеры (Service Workers, да простят меня читатели) сегодня являются полезным дополнением к основной функциональности сайта: тут и работа в оффлайне, и фоновая синхронизация данных, и модные пуш-уведомления.

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

Несколько сервис-воркеров на одном домене

У регистрации (registration) конкретного сервис-воркера есть такое понятие, как scope. Оно определяет, какие страницы на определённом домене будут подпадать под её контроль. При этом можно регистрировать несколько сервис-воркеров на одном домене, но с разными scope. Если попробовать зарегистрировать их с разными именами, но одним scope, то установленный позднее воркер будет «замещать» своего более раннего брата.

Кстати, для того, чтобы файл по указанному пути можно было установить в качестве сервис-воркера по пути выше (такое поведение запрещено по умолчанию, увеличивать путь можно, уменьшать — нет), то для этого можно использовать http-заголовок Service-Worker-Allowed.

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

Рассмотрим пример: у нас есть установленный сервис-воркер со scope /. Пусть это будет новостной сайт и мы предоставляем оффлайновые версии текстов. Также есть панель управления по пути /admin/ со своим собственным сервис-воркером. Если второй сервис-воркер ещё не попытались установить, то getRegistaration() будет возвращать регистрацию первого сервис-воркера и это может приводить к ошибкам (например, мы будем слать нотификации из панели администратора в сервис-воркер, не готовый к ним вовсе).

getRegistration имеет опциональный параметр — scope. Если его указать, то метод вернёт регистрацию, наиболее подходящую (не обязательно равную) переданному scope. Тем самым мы можем отписываться от сервис-воркеров на вложенных страницах или получать вообще любые регистрации с текущего домена, нужно лишь знать подходящие scope.

А если мы не знаем все scope, то есть метод getRegistrations(), который просто возвращает все регистрации с текущего домена в виде массива. Требуется Firefox или Chrome 45+.

Связь между страницей и сервис-воркером

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

Пример на serviceworke.rs показывает простой способ общения с сервис-воркером:

Здесь controller — сервис-воркер, контролирующий страницу. В свежих браузерах (все версии Firefox и Chrome 51+) можно достаточно просто ответить на такой запрос:

В более старых версиях приходилось обходить все вкладки и находить нужную, а то и создавать руками MessageChannel. Также теперь у нас есть возможность отправлять сообщение вкладке из события fetch. Всё это описано в статье, разве что современное апи у нас уже есть.

Другой момент — хранение данных в сервис-воркере. Люди, уже опробовавшие сервис-воркеры, могли заметить, что LocalStorage там нет. Всё потому, что в сервис-воркерах был взят курс на полностью асинхронное апи (за исключением, пожалуй, importScripts). Но внутри всё ещё остаются доступны:

• caches
• indexedDB
• просто переменные, объявленные в контексте воркера (но они недолговечны и будут позабыты при остановке сервис-воркера)

И caches, и indexedDB доступны обычным образом на страницах, полностью разделяя с воркером данные. Если обратиться к предыдущему параграфу, можно также прийти к выводу, что и несколько сервис-воркеров на одном origin будут разделять данные! В таком случае нужно не тереть кеши другого сервис-воркера, например, проверяя их по префиксу:

Или как-то так, но тогда нужно будет иметь в одном месте полный список возможных кешей.

Но при всём этом стоит помнить, что никто не гарантирует 100% сохранность данных в хранилищах. Браузер может автоматически чистить CacheStorage и indexedDB при нехватке места на диске, да и пользователь может сделать это сам.

Кроссдоменные запросы и прочее взаимодействие с другими доменами

С введением fetch ситуация могла показаться немного запутанной (там есть разные режимы запроса/ответа), а с сервис-воркерами всё становится в два раза сложнее: один fetch на стороне клиента, второй — на стороне сервис-воркера.

Самое простое понимание, к которому можно придти: «обмануть» CORS и получить доступ к контенту с другого домена без заголовков не получится. Важно разделять два вида использования: с доступом со стороны javascript и без него. Например, подменить одну картинку другой можно без проблем: достаточно указать в fetch сервис-воркера mode: ‘no-cors’ и не важно, какие там заголовки. Если не использовать ‘no-cors’, fetch будет ожидать CORS заголовки и в случае их отсутствия всё окончится ошибкой.

Если говорить более строго, то любой запрос (Request) со страницы имеет mode. Например, запрос картинки — ‘no-cors’, а запрос картинки с атрибутом crossOrigin (anonymous или use-credentials) — уже ‘cors’. Запросы через XMLHttpRequest всегда в режиме ‘cors’. А fetch позволяет задавать режим напрямую.

Ответ (Response) имеет свойство type. Запросы на текущий домен — ‘basic’. Иначе, если режим запроса — ‘cors’, то type ответа тоже будет ‘cors’, при наличии необходимых заголовков. Режим ответа ‘opaque’ можно получить на запрос в режиме ‘no-cors’, в нём нельзя получить доступ к каким-либо данным ответа.

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

Теперь попробуем всё скомбинировать. Со страницы уходит запрос, его перехватывает сервис-воркер и делает свой fetch, получает ответ. До текущего момента ситуация разобрана, но теперь будет нюанс: при передаче ответа с типом ‘opaque’ в ответ на запрос страницы. который был сделан не с режимом ‘no-cors’, мы получим ошибку.

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

Другая интересная возможность, которая сейчас находится в своей ранней версии — Foreign Fetch. Если обычный сервис-воркер контролирует запросы со страницы в своём scope (страница в scope, а не запросы), то foreign fetch позволяет контролировать запросы на свой домен. Допустим, обычное событие fetch будет срабатывать при запросе за библиотекой на CDN, а foreignFetch будет срабатывать при всех запросах за этой библиотекой на любых сайтах! Это любопытная возможность может быть использована, например, службами аналитики.

Тестирование

С написанием тестов на сервис-воркеры есть определённые сложности. Составление теста не так просто: если мы хотим проверить оффлайновый режим, то нужно как-то эмулиовать ошибки сети, если хотим проверить обновление — нужно подменять файл новым и тому подобное.

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

Есть стоящая статья на тему тестирования сервис-воркеров. В ней есть ссылки и на пару инструментов: sw-unit-test-sample и platinum-sw (элемент для Polymer, в нём есть также пара тестов). В статье также описан интересный приём: создание ифрейма для того, чтобы он контролировался тестируемым сервис-воркером. Вообще говоря, у элементов iframe и object есть другая особенность: запросы за ними и их содержимым идут в обход текущего сервис-воркера страницы, используя собственные сервис-воркеры.

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

Важный нюанс при работе автотестов — определение момента, когда сервис-воркер контролирует страницу и может перехватывать запросы. Простой navigator.serviceWorker.ready не всегда является верным решением — ready срабатывает в момент активации сервис воркера, но до того, как закончится выполнение clients.claim(). Более подробно описано здесь, как одно из решений — слушать событие controllerchange.

Обновление сервис-воркера

Есть несколько нюансов при обновлении сервис-воркеров, на которые стоит обратить внимание.

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

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

При обновлении часто добавляются в кеш из сети какие-то файлы. Но при этом работает браузерный кеш! Как и при вызовах fetch внутри сервис-воркера. Нужно либо быть уверенным, что файлы не поменялись (например, включать версию/хеш в название файла), либо загружать ресурсы в обход кеша. Чтобы загружать ресурсы в обход кеша, можно или руками звать fetch и потом добавлять ответ в кеш (не забывая проверять response.ok, например), или использовать опцию cache: ‘no-cache’ Request’а (пока работает только в Firefox Nightly). И то и то описано в статье Jake Archibald.

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

Источник

Как изменить размер выплаты на Эфириум-пуле 2Miners — подробная инструкция

В начале августа 2021 года в Эфириуме состоялся апдейт под названием London. Самыми заметными нововведениями в сети криптовалюты стали новая модель формирования комиссий за проведение транзакций и сжигание ETH. Вместе с этим майнинг-пулы больше не могут проводить транзакции с низкой стоимостью газа, что стало причиной появления новой модели выплаты на Эфириум-пуле 2Miners. Рассказываем, как изменить размер выплат для майнеров ETH.

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

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

Изменение размера минимальной выплаты возможно, только если хотя бы один ваш воркер подключен к пулу — то есть риг майнит и отправляет шары. Изменение размера минимальной выплаты производится на вкладке «Настройки аккаунта».

Для входа в ваш аккаунт (Страница «Статистика майнера») зайдите на главную страницу Ethereum Пула, расположенную на сайте пула 2Miners.

Введите ваш адрес кошелька, на который вы майните, в поле поиска «Адрес вашего кошелька».

Перейдите во вкладку «Настройки аккаунта».

Укажите желаемый размер выплаты в поле «Размер выплаты».

В поле «IP-адрес воркера» укажите IP-адрес того воркера, имя которого подсказывает Вам сайт.

IP-адрес должен заканчиваться так же как указано в подсказке на сайте (смотрите последние цифры).

Нажмите кнопку «Сохранить».

Если на странице появится сообщение «Настройки были успешно сохранены», значит изменение размера минимальной выплаты прошло успешно.

Изменение размера выплаты производится для всего аккаунта, независимо от количества воркеров в аккаунте. Вам необходимо указать IP-адрес только одного воркера.

Как найти необходимый IP-адрес в Windows

Подключитесь к воркеру (РИГ), IP-адрес которого Вам необходимо узнать. Войдите в ваш аккаунт (Страница «Статистика майнера») на пуле 2Miners. Перейдите во вкладку «Настройки аккаунта». Нажмите на ссылку «Как узнать свой IP?»

В браузере автоматически откроется страница сайта myIP, на которой будет указан нужный IP-адрес.

Как найти необходимый IP-адрес в RaveOS

RaveOS является популярным дистрибутивом операционной системы Linux, который создан специально для майнинга. В отличие от других систем, RaveOS полностью бесплатен для всех пользователей майнинг-пула 2Miners. Как майнить на RaveOS? Подробное описание и настройки майнинг-системы.

В интерфейсе RaveOS в разделе «Dashboard» выбираем тот воркер (РИГ), IP-адрес которого необходимо узнать.

Заходим на нужный нам воркер и переходим во вкладку «SYSTEM INFO».

На вкладке «SYSTEM INFO» показан нужный нам External IP (Внешний IP).

Внешний IP также можно узнать в консоли. Для этого необходимо в разделе «Dashboard» выбрать тот воркер (РИГ), IP-адрес которого необходимо узнать, и открыть командную строку.

Введите пароль по умолчанию (login: root; pass: admin) или ваш пароль, далее введите команду wget -qO- ifconfig.co. Получаем результат: IP-адрес.

Как найти необходимый IP-адрес в HiveOs

В панели мониторинга HiveOs переходим на вкладку «Workers» («Воркеры») и выбираем тот РИГ, IP-адрес которого необходимо узнать.

На вкладке «Overview» («Обзор») показан нужный нам Remote IP (Удалённый IP).

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

В командной строке необходимо ввести команду curl ifconfig.me/ip и нажать Run.

Через некоторое время на панели оповещения появится надпись curl ifconfig.me/ip. Нажимаем на неё.

Получаем результат: IP-адрес.

Как найти необходимый IP-адрес в SimpleMining OS

В интерфейсе SimpleMining OS в разделе «Rig List» выбираем тот воркер (РИГ), IP-адрес которого нужно узнать. Информация об IP-адресе, а нам нужен публичный адрес — pub, появляется после нажатия на кнопку «System Information».

Внешний IP также можно узнать в консоли. Для этого необходимо в разделе «Rig List» выбрать тот воркер (РИГ), IP-адрес которого нужно узнать, и открыть командную строку, выбрав Sellinabox.

При входе в консоль нужно ввести login: miner, pass: ваш e-mail.

Внимание: пароль не отображается при вводе пароля в поле для ввода – это особенность реализации SimpleMining OS.

Далее введите команду wget -qO- ifconfig.co. Получаем результат: IP-адрес.

Известные проблемы и варианты их решений

У некоторых пользователей возникают проблемы при попытке изменения размера минимальной выплаты. В этом случае на вкладке «Настройки аккаунта» сайт выдаёт сообщение «Указанный IP-адрес недействителен». С чем это может быть связано и как изменить размер выплаты в таком случае?

Проблема из-за смены динамического IP

Вы используете роутер или модем для доступа в интернет. Вы зашли на страницу своей статистики и перешли во вкладку «Настройки аккаунта». Сайт выдаёт Вам подсказку, вы ищете нужный воркер, чтобы узнать его IP-адрес. Если в это время ваш провайдер изменит ваш динамический IP-адрес, то при попытке изменения размера минимальной выплаты возникает ошибка.

Для решения проблемы обновите страницу вашей статистики в браузере и снова перейдите во вкладку «Настройки аккаунта». Проверьте подсказку сайта: посмотрите, IP-адрес какого воркера нужно указать и какие последние цифры этого IP, а затем снова попытайтесь изменить размер минимальной выплаты.

Проблема из-за одинакового хешрейта воркеров

У Вас работает несколько воркеров с одинаковым (почти одинаковым) хешрейтом. При попытке изменения размера минимальной выплаты возникает ошибка.

Из всех воркеров с одинаковым (почти одинаковым) хешрейтом оставьте работать на несколько минут только один, остальные остановите. Обновите страницу вашей статистики в браузере и снова перейдите во вкладку «Настройки аккаунта». Проверьте подсказку сайта: посмотрите, IP-адрес какого воркера нужно указать и какие последние цифры этого IP, а затем снова попытайтесь изменить размер минимальной выплаты.

Проблема из-за неработающих воркеров

Ни один ваш воркер не подключен к пулу (РИГ не майнит – не отправляет шары). Во вкладке «Настройки аккаунта» отсутствуют подсказки сайта: не написано имя воркера, для которого нужно вводить IP-адрес, а также не указаны последние цифры этого IP-адреса. При попытке изменения размера минимальной выплаты возникает ошибка.

Подключите хотя бы один ваш воркер к пулу, дождитесь, чтобы РИГ начал отправлять шары. Обновите страницу вашей статистики в браузере и снова перейдите во вкладку «Настройки аккаунта». Проверьте подсказку сайта: посмотрите, IP-адрес какого воркера нужно указать и какие последние цифры этого IP, а затем снова попытайтесь изменить размер минимальной выплаты.

Как давно вы майните? Расскажите об этом в нашем крипточате миллионеров. В нём поговорим и на другие темы, связанные с блокчейном и децентрализацией.

Источник