что такое служба rpc
Причины ошибки, когда сервер RPC недоступен в Windows 10 могут быть разные, но в основном это: служба(ы) требуемые для RPC отключены, удаленный помощник отключен в брандмауэре, IPV6 или общий доступ к файлам и принтерам отключен, IP-адрес приводит к сбою сервера RPC или службы RPC отключены в реестре. Давайте разберем эти моменты, чтобы исправить ошибку, когда удаленный вызов процедур дает сбой и появляется ошибка, что сервер RPC недоступен в Windows 10.
1. Проверка служб RPC
2. Удаленный помощник в брандмауэре
Нажмите Win+R и введите firewall.cpl, чтобы открыть параметры брандмауэра. Слева нажмите на «Разрешение взаимодействия с приложениями«.
Найдите «Удаленный помощник» и удостоверьтесь, что параметры для сети, включены везде. Перезагрузите компьютер или ноутбук, и проверьте, исправлена ли ошибка, когда сервер RPC недоступен.
3. Включение IPV6 и общего доступа к файлам и принтерам
В некоторых случаях вы можете столкнуться с ошибкой 1722: RPC сервер недоступен, когда происходит сбой сетевого подключения, так как отключены сетевой доступ к принтерам для сетей Microsoft и протокол TCP/IPv6.
Нажмите Win+R и введите ncpa.cpl, чтобы открыть сетевые адаптеры. Нажмите на сетевом адаптеры, через которое идет сеть, и выберите «свойства». Далее в списке найдите два параметра и убедитесь что они включены (галочки установлены).
Если ошибка «сервер RPC недоступен» с кодом 1722 все еще появляется, то двигаемся ниже.
4. Очистить DNS
Очистка старых DNS может исправить код ошибки 1722 RPC. В первую очередь убедитесь, что службы, связанные с RPC, работают как в способе 1. Далее запускаем командную строку от имени администратора и введите следующие команды для очистки и сброса DNS:
Проверьте, исправлена ли ошибка 1722 RPC недоступен.
5. Редактор реестра для запуска RPC служб
Если вы не смогли запустить службы способом 1, то запустим их через реестр. Для полной эффективности, убедитесь, что вы проделали способ 3 и способ 4. Нажмите Win+R и введите regedit, чтобы открыть редактор реестра.
И еще по одному пути:
Перезагрузите ПК и проверьте, исправлена ли ошибка, когда RPC сервер недоступен в Windows 10.
Службы и RPC/TCP
начиная с Windows Vista диспетчер управления службами (SCM) поддерживает удаленные вызовы процедур по протоколу управления передачей (rpc/TCP) и именованным каналам (rpc/NP). Функции SCM на стороне клиента используют RPC/TCP по умолчанию.
RPC/TCP подходит для большинства приложений, использующих функции SCM удаленно, таких как средства удаленного администрирования или мониторинга. Однако для обеспечения совместимости и производительности некоторым приложениям может потребоваться отключить RPC/TCP, задав значения реестра, описанные в этом разделе.
Когда служба вызывает удаленную функцию SCM, клиентский модуль SCM сначала пытается использовать RPC/TCP для связи со службой SCM на стороне сервера. если сервер работает под управлением версии Windows, поддерживающей rpc/tcp и разрешающей трафик rpc/tcp, подключение rpc/ткпп будет выполняться. если сервер работает под управлением версии Windows, которая не поддерживает rpc/tcp, или поддерживает rpc/tcp, но работает за брандмауэром, который разрешает только именованный канал, истекает время ожидания подключения rpc/tcp, и SCM повторяет подключение к rpc/NP. В конечном итоге это будет выполнено, но может занять некоторое время (обычно более 20 секунд), в результате чего функция OpenSCManager будет заблокирована.
Значения реестра RPC/TCP
В следующей процедуре описывается, как отключить RPC/TCP на стороне клиента.
Отключение RPC/TCP на стороне клиента
В следующей процедуре описывается, как отключить TCP на стороне сервера.
Отключение протокола TCP на стороне сервера
В следующей процедуре описывается, как отключить RPC/TCP и RPC/NP на сервере (например, чтобы уменьшить поверхность атаки).
Отключение RPC/TCP и RPC/NP на сервере
Значение реестра скмапиконнектионпарам можно также использовать для указания интервала времени ожидания RPC/TCP в миллисекундах. Например, значение 30 000 указывает интервал времени ожидания 30 секунд. Значение по умолчанию — 21 000 (21 секунда).
RPC, Messaging, REST: Терминология
Цель данной статьи — обсудить терминологию. Статья — не о том, как и для чего, а только исключительно об использовании терминологии. Статья отражает мнение автора и не претендует на научность.
Вступление
Если вы работаете в области программирования распределенных систем или в интеграции систем, то большая часть изложенного здесь вам не в новинку.
Проблема возникает, когда встречаются люди, использующие разные технологии, и когда эти люди начинают технические разговоры. При этом часто возникает взаимное недопонимание, обусловленное терминологией. Я здесь попытаюсь свести воедино терминологии, используемые в разных контекстах.
Терминология
Четкой терминологии и классификации в этой области нет. Используемая ниже терминология является отражением модели, сложившейся у автора, то есть она строго субъективна. Любая критика и любые обсуждения приветствуются.
Я разделил терминологию на три области: RPC (Remote Procedure Call), Messaging и REST. Эти области имеют под собою исторические корни.
RPC технологии — наиболее старые технологии. Наиболее яркие представители RPC, это — CORBA и DCOM.
В те времена в основном приходилось связывать системы в быстрых и относительно надежных локальных сетях. Главная идея RPC была в том, чтобы сделать вызов удаленных систем очень похожим на вызов функций внутри программы. Вся механика удаленных вызовов пряталась от программиста. По крайней мере её пытались спрятать. Программисты во многих случаях вынуждены были работать на более глубоком уровне, где появлялись термины маршалинг (marshalling) и unmarshalling (как это по-русски?), что по сути означало сериализацию. Обычные вызовы функций внутри процессов обрабатывались на вызывающей стороне в Proxy, а на стороне системы, выполняющей функцию, в Dispatcher. В идеале ни вызывающая система, ни обрабатывающая система не занимались тонкостями передачи данных между системами. Все эти тонкости сосредотачивались в связке Proxy — Dispatcher, код которых генерировался автоматически.
Поэтому вы не заметите, не должны заметить, никакой разницы между вызовом локальной функции и вызовом удаленной функции.
Сейчас наблюдается своеобразный ренесанс RPC, наиболее яркие представители которого: Google ProtoBuf, Thrift, Avro.
Messaging
С течением времени выяснилось, что попытка оградить программиста от того, что вызываемая функция все же отличается от локальной, не привела к желаемому результату. Детали реализации и принципиальные отличия распределенных систем были слишком велики, чтобы решаться с помощью автоматически генерируемого кода Proxy. Постепенно пришло понимание, что факт того, что системы связывает ненадежная, медленная, низкоскоростная среда, должен быть явно отражен в коде программы.
Появились технологии веб-сервисов. Мы стали говорить ABC: Address, Binding, Contract. Не совсем понятно, почему появились контракты, которые по сути являются Envelope (конвертами) для входных аргументов. Контракты чаще усложняют всю модель, чем упрощают ее. Но… неважно.
Теперь программист явным образом создавал сервис (Service) или клиента (Client), вызывающего сервис. Сервис представлял из себя набор операций (Operation), каждая из которых на входе принимала запрос (Request) и выдавала ответ (Response). Клиент явным образом посылал (Sent) запрос, сервис явным образом получал (Receive) его и отвечал (Sent), высылая ответ. Клиент получал (Receive) ответ и на этом вызов завершался.
Так же, как и в RPC, где-то здесь работали Proxy и Dispatcher. И как прежде их код генерировался автоматически и программисту не надо было в нем разбираться. Разве только что, клиент явным образом использовал классы из Proxy.
Запросы и ответы явным образом преобразуются к формату, предназначенному для передачи по проводам. Чаще всего это массив байт. Преобразование называется Serialization и Deserialization и иногда прячется в коде Proxy.
Кульминация messaging проявилась в появлении парадигмы ESB (Enterprise Service Bus). Никто толком не может сформулировать, что это такое, но все сходятся на том, что данные по ESB движутся в виде сообщений.
В постоянной борьбе со сложностью кода, программисты сделали очередной шаг и создали REST.
Основной принцип REST в том, что операции-функции резко ограничили и оставили только набор операций CRUD: Create — Read — Update — Delete. В этой модели все операции всегда применяются к некоторым данным. Имеющихся в CRUD операций достаточно для большей части приложений. Так как REST технологии в большинстве случаев подразумевают использование протокола HTTP, то команды CRUD отразились на команды HTTP (Post — Get — Put — Delete). Постоянно утверждается, что REST не обязательно привязан к HTTP. Но на практике повсеместно используется отражение сигнатур операций на синтаксис HTTP команд. К примеру, вызов функции
EntityAddress ReadEntityAddress(string param1, string param2)
выразится в таком виде:
Заключение
Прежде, чем начинать дискуссию по распределенным системам или по интеграции, определитесь с терминологией. Если Proxy всегда будет означать одно и то же в разных контекстах, то, к примеру, request мало что будет значить в терминах RPC, а marshalling вызовет недоумение при обсуждении REST технологий.
Как работает RPC
Средства удаленного вызова процедур делают его пользователям, как будто клиент напрямую вызывает процедуру, расположенную в удаленной серверной программе. У каждого клиента и сервера есть свои адресные пространства; то есть каждый из них имеет свой собственный ресурс памяти, выделенный для данных, используемых процедурой. На следующем рисунке показана архитектура RPC.
Как показано на рисунке, клиентское приложение вызывает локальную процедуру-заглушку вместо фактического кода, реализующего процедуру. Заглушки компилируются и связываются с клиентским приложением. Вместо того, чтобы содержать фактический код, реализующий удаленную процедуру, код заглушки клиента:
Для вызова удаленной процедуры сервер выполняет следующие действия.
Затем выполняется удаленная процедура, которая, возможно, создает выходные параметры и возвращаемое значение. После завершения удаленной процедуры аналогичная последовательность действий возвращает клиенту данные.
Клиент завершает процесс, принимая данные по сети и возвращая их вызывающей функции.
Библиотеки времени выполнения предоставляются в двух частях: библиотеку импорта, которая связана с приложением и библиотекой времени выполнения RPC, которая реализована как библиотека динамической компоновки (DLL).
Серверное приложение содержит вызовы функций библиотеки времени выполнения сервера, которые регистрируют интерфейс сервера и позволяют серверу принимать удаленные вызовы процедур. Серверное приложение также содержит удаленные процедуры, связанные с конкретным приложением, которые вызываются клиентскими приложениями.
Служба RPC — как запустить?
Иногда при ручном запуске службы удаленного вызова процедур (RPC), появляется ошибка, которая мешает функционированию данной службы.
Ошибка выглядит следующим образом:
«Не удалось запустить службу удаленного вызова процедур (RPC). Ошибка 1058: Служба не может быть запущена, поскольку она отключена или все связанные с ней устройства отключены.»
Ошибка говорит о том, что служба удаленного вызова процедур для использующегося профиля оборудования в данный момент не запущена – отключена!
Давайте перейдем к этапу устраняя данной проблемы. Внимание! Все вышеописанное может нанести вред реестру, поэтому выполнять следует все аккуратно, шаг за шагом. Желательно, перед выполнением описанных ниже рекомендаций произвести резервное копирование данных. В случае, если что-то пойдет не так, вы сможете восстановить вашу операционную систему.
Итак, инструкция взята с официального сайта Майкрософт. Вот, что они советуют.
Перезагрузите компьютер в Безопасном режиме. Чтобы сделать это, выполните следующие действия.
Перезагрузите компьютер и при появлении меню загрузки нажмите клавишу F8.
В Меню дополнительных вариантов загрузки Windowsвыберите Безопасный режими нажмите клавишу ВВОД.
Когда повторно появится меню загрузки со словами в нижней части меню «безопасный режим», выберите операционную систему, которую требуется запустить и нажмите клавишу ВВОД.
Нажмите кнопку Пуск, выберите пункт Выполнить, введите команду regedit и нажмите кнопку ОК.
В левой области найдите и выделите следующий подраздел реестра:
В меню файл выберите команду Экспорт.
В поле имя файла введите имя для файла реестра.
В списке Сохранить в выберите расположение, где требуется сохранить файл реестра и нажмите кнопку Сохранить.
Щелкните правой кнопкой мыши LEGACY_RPCSSи выберите команду Удалитьв диалоговом окне Подтверждение удаления раздела нажмите кнопку Да.
Примечание. Не удаляйте один из следующих разделов, которые можно найти в подразделе КОРНЯ:
Закройте редактор реестра.
Перезагрузите компьютер с помощью параметра Обычная перезагрузка Windows при запуске.
Таким образом, мы разобрались с сегодняшней проблемой. И это именно тот случай, когда решение продиктовано компанией, которая произвела на свет вашу операционную систему.