Удаленный вызов процедур rpc как включить

Содержание

Fix: не запускается служба

Удаленный вызов процедур rpc как включить

После перезагрузки компа не запустилась служба “Удаленный вызов процедур (RPC)“. Очень многое зависит от этой службы.

В итоге не работает восстановление системы, сетевое окружение, звук, Windows Installer, почти не работает консоль управления (MMC), на панели задач не показываются открытые окна и т.д. и т.п. Попытка ручного запуска приводит к ошибке “Неудается запустить .

..

(RPC) на xxxComp. Ошибка 5: Отказано в доступе“. Антивирус ничего не нашел. Два дня копаний и комп удалось вернуть к жизни.

По рекомендации Microsoft, первое, что пробовал, найти и удалить ветку реестра [HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Enum\ROOT\LEGACY_RPCSS]. Ее у меня не оказалось, возможно в результате каких-то установленных обновлений.

Далее, попытка восстановить параметры службы в реестре. Поскольку regedit.exe работал только на чтение/удаление (еще один побочный эффект), не получилось внести изменения. Да они и не нужны были, т.к. все было верно. Должно выглядеть вот так:

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs] “Description”=”Обеспечивает сопоставление конечных точек и иных служб RPC.” “DisplayName”=”Удаленный вызов процедур (RPC)” “ErrorControl”=dword:00000001 “Group”=”COM Infrastructure” “ImagePath”=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\ 74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,73,\ 00,76,00,63,00,68,00,6f,00,73,00,74,00,20,00,2d,00,6b,00,20,00,72,00,70,00,\ 63,00,73,00,73,00,00,00 “ObjectName”=”NT AUTHORITY\etworkService” “Start”=dword:00000002 “Type”=dword:00000010 “FailureActions”=hex:00,00,00,00,00,00,00,00,00,00,00,00,01,00,00,00,00,00,00,\ 00,02,00,00,00,60,ea,00,00 “ServiceSidType”=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Parameters] “ServiceDll”=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\ 00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\ 72,00,70,00,63,00,73,00,73,00,2e,00,64,00,6c,00,6c,00,00,00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Security] “Security”=hex:01,00,14,80,a8,00,00,00,b4,00,00,00,14,00,00,00,30,00,00,00,02,\ 00,1c,00,01,00,00,00,02,80,14,00,ff,01,0f,00,01,01,00,00,00,00,00,01,00,00,\ 00,00,02,00,78,00,05,00,00,00,00,00,14,00,8d,00,02,00,01,01,00,00,00,00,00,\ 05,0b,00,00,00,00,00,18,00,ff,01,0f,00,01,02,00,00,00,00,00,05,20,00,00,00,\ 20,02,00,00,00,00,18,00,8d,00,02,00,01,02,00,00,00,00,00,05,20,00,00,00,23,\ 02,00,00,00,00,14,00,9d,00,00,00,01,01,00,00,00,00,00,05,04,00,00,00,00,00,\ 18,00,9d,00,00,00,01,02,00,00,00,00,00,05,20,00,00,00,21,02,00,00,01,01,00,\ 00,00,00,00,05,12,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs\Enum] “0”=”Root\\LEGACY_RPCSS\\0000″ “Count”=dword:00000001 “NextInstance”=dword:00000001

Значение параметра start может отличаться. Изменить реестр все же можно, но при этом нужно загрузиться с MS ERD commander.

Следующие шаги просто распишу по пунктам. Общая идея в том, что нужно заменить файлы на заведомо рабочие. Их можно взять с другой машины или из дистрибутива Windows (как я сделал).

  • Запустить консоль (Пуск > Выполнить: cmd)
  • cd z:\i386 (там дистрибутив Windows)
  • expand explorer.ex_ %TEMP%\explorer.exe
  • expand svchost.ex_ %TEMP%\svchost.exe
  • Запустить Диспетчер задач (Ctrl+Shift+Esc)
  • Остановить процесс exlporer.exe
  • copy %TEMP%\explorer.exe %SYSTEMROOT% /y
  • Остановить все процессы svchost.exe. Внимание! После этого у вас будет 60 секунд до перезагрузки машины.
  • copy %TEMP%\svchost.exe %systemroot%\system32 /y

Этот финт тоже не дал результатов. Еще вариант: запустить проверку всех защищенных системных файлов с заменой неправильных версий правильными. В консоли выполнить:

Не помогло.. Тогда совсем брутальный ход – восстановление параметров безопасности. Опять же в консоли:

После перезагрузки комп заработал, базовые сервисы стартовали. Появился новый косяк (а может он был с самого начала): под моей учеткой не запускался, как минимум, менеджер управления дисками и Windows Installer. Отказано в доступе. Можно через консоль восстановить права доступа к системному диску “по умолчанию”:

После чего нужно в ручную определить права для каждой учетки к [c:\Documents and Settings\UserXXX] или пересоздать их, смотря что проще.

В моем случае я просто назначил одинаковые права на весь системный диск, взяв за эталон доступ к каталогу [c:\windows]. К эталону добавил свою учетку в домене с полными правами к диску. Может это неправильно с точки зрения безопасности, но копаться с каждым каталогом отдельно у меня времени нет.

Возможно ручное добавление как-то бы изменило ситуацию.

Попытки ручного запуска сервиса, например через команду “net start rcpss” заканчивались ошибкой “Error 5: access denied“. Я предполагаю, отказано в доступе потому, что сервис должен запускаться под учеткой системы – “NT AUTHORITY”. В реестре есть такой параметр:

Я бы попытался вписать сюда админскую учетку и опять запустить сервис. Но это только идея, не дожившая до реализации.

Еще вариант: использование эксплоита KiTrap0D для получения консоли с правами системы. Об этом эксплоите писали в Хакере. Собственно бинарник здесь. Вот только у меня стоят виндовские обновки, так что похоже данный эксплоит уже не работает.

1 ноября 2012

ОС: WindowsXP. Давно не обновлял видеодрайвер, т.к. прекрасно все работало. Сел играться в Prototype 2, получил несколько неприятных артефактов в изображении. Дальше все пошло по наклонной :(. Cкачал самый новый драйвер.

Перед установкой создал точку восстановления. Поставил, перегрузился и чувствую, что где-то подвох. Некоторые шрифты нормальные, а некоторые – размытые. Мелькнула же мысль, что косяк с конкретным семейством шрифтов, но т.к.

занят был игрой, а не Windows, не стал разбираться.

hard'n'soft, WinXP, терапия

4 сентября 2012

IRST (Intel RST) – Intel Rapid Storage Technology – программная разработка Intel, обеспечивающая высокую производительность SATA-винчестеров и RAID-SATA-массивов в поддерживаемых операционных системах (перевод из мануала).

Этот продукт сменил Intel Matrix Storage Manager. Не знаю, зачем вам такая программа, тем более на Windows XP, но раз вы читаете эти строки, значит “НАДО” 😉 У себя на нетбуке я пытался ее поставить, ибо не ведал, что творю.. То бишь из любопытства ставил.

Рассказываю, как подружить IRST и WinXP.

hard'n'soft, WinXP, ламерOff

6 марта 2012

Поразительно, как могут осложниться простые вещи в сочетании с кривым софтом. Задача элементарная: назначить для просмотра tif-файлов программу MS Office Document Imaging. Нужный файл – [C:\Program Files\Common Files\Microsoft Shared\MODI\12.0\Mspview.exe].

Это достаточно удобная софтина с минимальными возможностями работы с изображением и распознованием текста. Для офисной работы самое то.. Но почему-то она по умолчанию не связывается с tif-файлами при установке офиса, и исправлять ситуацию приходится руками.

Почти все описанное ниже применимо в целом к задаче назначения приложения для файла, независимо от типа/расширения.

MS Office, WinXP, терапия

15 декабря 2011

После перезагрузки компа не запустилась служба “Удаленный вызов процедур (RPC)“. Очень многое зависит от этой службы.

В итоге не работает восстановление системы, сетевое окружение, звук, Windows Installer, почти не работает консоль управления (MMC), на панели задач не показываются открытые окна и т.д. и т.п. Попытка ручного запуска приводит к ошибке “Неудается запустить .

..

(RPC) на xxxComp. Ошибка 5: Отказано в доступе“. Антивирус ничего не нашел. Два дня копаний и комп удалось вернуть к жизни.

WinXP, администрирование, терапия

1 декабря 2011

При запуске программы получается ошибка “Приложение не было запущено, поскольку оно некорректно настроено“. Очень полезная инфа, нефиг сказать 🙂 Далее в этом же сообщении предлагается переустановить приложение. Итак, почему вдруг на чистой машине с только что установленной WinXP перестала работать любимая игра или программулина?

WinXP, кодинг, терапия

11 ноября 2011

На машине под WinXP стоит Office 2007. При его установке добавился виртуальный принтер “Отправить в OneNote 2007“. Зачем он нужен, я без понятия, у нас этой фишкой все равно никто не пользуется. Кстати, раньше (до 2007-го офиса), в принтерах болтался “Document image writer“. Проблема: при запуске любого приложения из пакета Office комп зависает, т.к. один процесс жрет 100% ЦП.

Процесс spoolsv.exe, занимающий все процессорное время – это диспетчер очереди печати. И парится он так, потому что на виртуальном принтере висят задания на печать. После их удаления все приходит в норму 🙂 К слову сказать, до этого я пробовал: перегрузжать машину, перезапуск службы, переустановку Office, замену файла spoolsv.exe, понижение приоритета этого процесса.

[1oo%, EoF] MS Office, WinXP, терапия

1 августа 2011

Задача: организовать сеть из двух (или больше) машин в рабочей группе под управлением Windows XP.

Казалось бы, что может быть проще 🙂 Однако, есть некоторые тонкости, которые могут поставить в тупик даже опытного пользователя. Кстати, “о птичках..

” Материал расчитан именно на опытных пользователей, которым не нужно рассказывать, как обжать кабель или что такое ping. Все изложено коротко и четко, расписывать азы по буквам нет времени и желания.

21 июля 2011

Вам знакома ситуация, когда машина стала заметно тормозить и в итоге вы получаете сообщение “Недостаточно места на диске С. Запустить мастер очистки..“? Можно воспользоваться предложением и запустить мастер, а можно покопаться в Винде, почистить все руками и настроить некоторые системные параметры на оптимальную работу. Для примера возьмем Windows XP.
hard'n'soft, WinXP, ликбез

23 мая 2011

Стоит на машине MS Office 2003. Установка выполнялась из сети. Теперь возникла необходимости кое-что добавить. Пакет установки более не доступен, а другое место пакета инсталлятор не спрашивает! Знаю, обычно спрашивает, но вот именно здесь образовался глюк 🙁

Пытался снести текущую установку, запускал инсталляцию из другого источника, танцевал с бубном.. Куда не ткнусь, везде получаю “Не удается открыть пакет исправлений. Убедитесь, что пакет существует и у вас есть доступ к нему, или обратитесь к поставщику приложений и убедитесь, что используется соответствующая версия обновления установщика Windows.”

На сайте поддержки Microsoft есть указания, как это пофиксить. Инструмент: служебная программа очистки установщика Windows. Но файл Msicuu2.exe, скачанный по их ссылке, нихрена не работает.

Рабочий вариант можно скачать здесь.

Инсталляция не требуется, распаковываем архив, пользуемся 🙂 Кстати, оригинальная установка этой софтины тоже не без косяков проходила – после установки ярлык в пуске не правильно создался.

[1oo%, EoF]

12 мая 2011

Существует такая вещь как “кодовая страница”. Не вдаваясь в подробности, скажу, что выбор правильной страницы позволит читать русские тексты в Винде.

Так вот столкнулся в проблемой: главное меню (только оно) одной программы написано крякозябрами. Два дня как крот копался в инете и трех компах дабы вычислить причину.

Очевидные вещи, типа региональных настроек конечно проверил сразу же.

Источник: https://waredom.ru/64

Сервер RPC недоступен в Windows 10 – Как исправить?

Удаленный вызов процедур rpc как включить

Remote Process Call (RPC) в переводе “удаленный вызов процедур” – это протокол, который позволяет программам на одном компьютере получать доступ к определенным службам программы на другом компьютере, который находится в той же сети. Другими словами, его основная цель, это дать возможность клиенту и серверу взаимодействовать друг с другом по сети.

Но, иногда пользователи сталкиваться с ошибкой “Сервер RPC недоступен” в Windows 10, и ошибка может появляться при подключении к удаленному рабочему столу, при попытке распечатать документ на сетевом принтере, в почте outlook, abbyy licensing service и т.п.

Недоступность RPC может быть не только по локальной сети, а так же в периферийных устройствах контроллера как сканер или принтер.

Причины ошибки, когда сервер RPC недоступен в Windows 10 могут быть разные, но в основном это: служба(ы) требуемые для RPC отключены, удаленный помощник отключен в брандмауэре, IPV6 или общий доступ к файлам и принтерам отключен, IP-адрес приводит к сбою сервера RPC или службы RPC отключены в реестре. Давайте разберем эти моменты, чтобы исправить ошибку, когда удаленный вызов процедур дает сбой и появляется ошибка, что сервер RPC недоступен в Windows 10.

1. Проверка служб RPC

Службы RPC могут перейти от автоматического режима в ручной, что и будет вызывать ошибку. Первым делом стоит проверить службу. Нажмите сочетание кнопок Win+R и введите services.

msc, чтобы быстро открыть службы. В предоставленном списке найдите следующие службы и нажмите правой кнопкой мыши, выберите “свойства”.

Задайте параметры, если у вас не так – Тип запуска: Автоматически и запустить, если служба остановлена.

  1. Локатор удаленного вызова процедур (RPC).
  2. Модуль запуска процессов DCOM-сервера.
  3. Удаленный вызов процедур (RPC).

Примечание:

  • Если у вас ошибка связанная с программой ABBYY licensing service, то ищите службу с названием ABBYY FineReader и установить для нее те же значения.
  • Если у вас стоят не правильные параметры и не можете ничего изменить (выделено все серым), то следуйте 5 способу.

2. Удаленный помощник в брандмауэре

Удаленный помощник – функция, которая позволяет другим пользователям или компьютерам видеть экран вашего компьютера и управлять им. При подключении к удаленному компьютеру, вы также можете столкнуться с ошибкой RPC, поскольку клиент и сервер обмениваются информацией в гораздо большем и сложном масштабе. Если брандмауэр не настроен, вы увидите ошибку “Сервер RPC недоступен”.

Нажмите Win+R и введите firewall.cpl, чтобы открыть параметры брандмауэра. Слева нажмите на “Разрешение взаимодействия с приложениями“.

Найдите “Удаленный помощник” и удостоверьтесь, что параметры для сети, включены везде. Перезагрузите компьютер или ноутбук, и проверьте, исправлена ли ошибка, когда сервер RPC недоступен.

3. Включение IPV6 и общего доступа к файлам и принтерам

В некоторых случаях вы можете столкнуться с ошибкой 1722: RPC сервер недоступен, когда происходит сбой сетевого подключения, так как отключены сетевой доступ к принтерам для сетей Microsoft и протокол TCP/IPv6.

Нажмите Win+R и введите ncpa.cpl, чтобы открыть сетевые адаптеры. Нажмите на сетевом адаптеры, через которое идет сеть, и выберите “свойства”. Далее в списке найдите два параметра и убедитесь что они включены (галочки установлены).

  1. Общий доступ к файлам и принтерам для сетей Microsft.
  2. IP версии 6 (TCP/IPv6).

Если ошибка “сервер RPC недоступен” с кодом 1722 все еще появляется, то двигаемся ниже.

4. Очистить DNS

Очистка старых DNS может исправить код ошибки 1722 RPC. В первую очередь убедитесь, что службы, связанные с RPC, работают как в способе 1. Далее запускаем командную строку от имени администратора и введите следующие команды для очистки и сброса DNS:

  • ipconfig /flushdns
  • ipconfig /renew

Проверьте, исправлена ли ошибка 1722 RPC недоступен.

5. Редактор реестра для запуска RPC служб

Если вы не смогли запустить службы способом 1, то запустим их через реестр. Для полной эффективности, убедитесь, что вы проделали способ 3 и способ 4. Нажмите Win+R и введите regedit, чтобы открыть редактор реестра.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcSs
  • Справа щелкните два раза мышкой по Start и установите значение 2 с шестнадцатеричной системой.
  • Это активирует удаленный вызов процедур (RPC).

Далее перейдите:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DcomLaunch
  • Откройте параметр Start и задайте значение 2 с шестнадцатеричной системой.
  • Это запустит модуль запуска процессов DCOM-сервера.

И еще по одному пути:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RpcEptMapper
  • Откройте параметр Start и задайте значение 2 с шестнадцатеричной системой.
  • Это запустит локатор удаленного вызова процедур (RPC).

Перезагрузите ПК и проверьте, исправлена ли ошибка, когда RPC сервер недоступен в Windows 10.

Загрузка комментариев

Источник: https://mywebpc.ru/windows/the-rpc-server-is-unavailable/

RabbitMQ tutorial 6 — Удаленный вызов процедур

Удаленный вызов процедур rpc как включить

В продолжение пятого урока по изучению азов RabbitMQ, публикую перевод шестого урока с официального сайта. Все примеры написаны на python (используется pika версии 0.9.8), но по-прежнему их можно реализовать на большинстве популярных ЯП.

Во втором уроке мы рассмотрели использование очередей задач для распределения ресурсоёмких задач между несколькими подписчиками.

Но что если мы захотим запустить функцию на удаленной машине и дождаться результата? Ну, это совсем другая история. Этот шаблон широко известен как Удаленный Вызов Процедур (Remote Procedure Call или RPC, далее в тексте RPC). В этом руководстве мы построим, используя RabbitMQ, RPC систему, которая будет включать клиент и масштабируемый RPC сервер. Так как у нас нет реальной трудоемкой задачи требующей распределения, мы создадим простой RPC сервер, возвращающий числа Фибоначчи.

Интерфейс клиента

Для иллюстрации использования RPC службы, создадим простой клиентский класс. Этот класс будет содержать метод call, который будет отправлять RPC запросы и блокироваться до получения ответа: fibonacci_rpc = FibonacciRpcClient()result = fibonacci_rpc.

call(4)print “fib(4) is %r” % (result,)
Несмотря на то, что RPC довольно распространенный шаблон, его часто критикуют. Проблемы обычно возникают, когда разработчик не знает точно, какую функцию он использует: локальную или медленную, выполняющуюся посредством RPC.

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

С учетом вышеизложенного можно дать следующие рекомендации:

  • Убедитесь, что это очевидно, какая функция вызывается в каждом конкретном случае: локальная или удаленная;
  • Документируйте вашу систему. Делайте зависимости между компонентами явными;
  • Обрабатывайте ошибки. Как должен реагировать клиент, если RPC сервер не отвечает в течение длительного промежутка времени?
  • Если сомневаетесь — не используйте RPC. Если это возможно, используйте асинхронный конвейер вместо блокирующего RPC, когда результаты асинхронно передаются на следующий уровень обработки.

Очередь результатов

Вообще, совершать RPC через RabbitMQ легко. Клиент отправляет запрос и сервер отвечает на запрос. Чтобы получить ответ, клиент должен передать очередь для размещения результатов вместе с запросом. Давайте посмотрим как это выглядит в коде: result = channel.

queue_declare(exclusive=True)callback_queue = result.method.queue channel.basic_publish(exchange='', routing_key='rpc_queue', properties=pika.BasicProperties( reply_to = callback_queue, ), body=request) # …

какой-то код для чтения ответного сообщения из callback_queue …

Свойства сообщений

В протоколе AMQP имеется 14 предопределенных свойств сообщений. Большинство из них используются крайне редко, за исключением следующих:

  • delivery_mode: отмечает сообщение как «стойкое» (со значением 2) или «временное» (любое другое значение). Вы должны помнить это свойство по второму уроку;
  • content_type: используется для описания формата представления данных(mime). К примеру, для часто используемого JSON формата хорошим тоном считается устанавливать это свойство в application/json;
  • reply_to: обычно используется для указания очереди результатов;
  • correlation_id: свойство используется для сопоставления RPC ответов с запросами.

Correlation id

В методе, представленном выше, мы предлагали создавать очередь ответов для каждого RPC запроса. Это несколько избыточно, но, к счастью, есть способ лучше — давайте создадим общую очередь результатов для каждого клиента.

Это поднимает новый вопрос, получив ответ из этой очереди не совсем ясно, какому запросу соответствует этот ответ. И тут нам пригодится свойство correlation_id. Мы будем присваивать этому свойству уникальное значение при каждом запросе.

Позднее, когда мы извлечем полученный ответ из очереди ответов, основываясь на значении этого свойства мы сможем однозначно сопоставить запрос с ответом.

Если встретим неизвестное значение в свойстве correlation_id, мы можем спокойно игнорировать это сообщение, так как оно не соответствует ни одному из наших запросов.

Вы могли бы поинтересоваться, почему мы планируем просто игнорировать неизвестные сообщения из очереди ответов, вместо того, чтобы прервать выполнение сценария? Это связано с вероятностью возникновения race condition на стороне сервера. Хотя это и маловероятно, но вполне возможен сценарий, при котором RPC сервер отправит нам ответ, но не успеет отправить подтверждение обработки запроса. Если это произойдет, перезапущенный RPC сервер снова будет обрабатывать данный запрос. Вот почему на клиенте мы должны корректно обрабатывать повторные ответы. Кроме того, RPC, в идеале, должен быть идемпотентен.

Итоги

Наш RPC будет работать следующим образом: — Когда Клиент стартует, он создает анонимную уникальную очередь результатов;

— Для совершения RPC запроса, Клиент отправляет сообщение с двумя свойствами: reply_to, где в качестве значения указывается очередь результатов и correlation_id, устанавливаемый в уникальное значение для каждого запроса.

— Запрос отправляется в очередь rpc_queue;
— Сервер ожидает запросы из этой очереди. Когда запрос получен, Сервер выполняет свою задачу и отправляет сообщение с результатом обратно Клиенту, используя очередь из свойства reply_to;
— Клиент ожидает результат из очереди результатов. Когда сообщение получено, Клиент проверяет свойство correlation_id. Если оно соответствует значение из запроса, то результат отправляется приложению.

Собирая всё вместе

Код сервера rpc_server.py: #!/usr/bin/env pythonimport pika connection = pika.BlockingConnection(pika.ConnectionParameters( host='localhost')) channel = connection.channel() channel.

queue_declare(queue='rpc_queue') def fib(n): if n == 0: return 0 elif n == 1: return 1 else: return fib(n-1) + fib(n-2) def on_request(ch, method, props, body): n = int(body) print ” [.] fib(%s)” % (n,) response = fib(n) ch.basic_publish(exchange='', routing_key=props.reply_to, properties=pika.BasicProperties(correlation_id = \ props.

correlation_id), body=str(response)) ch.basic_ack(delivery_tag = method.delivery_tag) channel.basic_qos(prefetch_count=1)channel.basic_consume(on_request, queue='rpc_queue') print ” [x] Awaiting RPC requests”channel.

start_consuming() Серверный код довольно прост:

  • (4) Как обычно, мы устанавливаем соединение и объявляем очередь;
  • (11) Объявляем нашу функцию, возвращающую числа Фибоначчи, которая принимает в качестве аргумента только целые положительные числа(эта функция вряд ли будет работать с большими числами, вероятнее всего это самая медленная из возможных реализаций);
  • (19) Мы объявляем функцию обратного вызова on_request для basic_consume, которая и является ядром RPC сервера. Она исполняется когда запрос получен. Выполнив работу, функция отправляет результат обратно;
  • (32) Вероятно, мы захотим когда-нибудь запустить более одного сервера. Для равномерного распределения нагрузки между несколькими серверами мы устанавливаем prefetch_count.

Код клиента rpc_client.py: #!/usr/bin/env pythonimport pikaimport uuid class FibonacciRpcClient(object): def __init__(self): self.connection = pika.BlockingConnection(pika.ConnectionParameters( host='localhost')) self.channel = self.connection.channel() result = self.channel.queue_declare(exclusive=True) self.callback_queue = result.method.queue self.channel.basic_consume(self.on_response, no_ack=True, queue=self.callback_queue) def on_response(self, ch, method, props, body): if self.corr_id == props.correlation_id: self.response = body def call(self, n): self.response = None self.corr_id = str(uuid.uuid4()) self.channel.basic_publish(exchange='', routing_key='rpc_queue', properties=pika.BasicProperties( reply_to = self.callback_queue, correlation_id = self.corr_id, ), body=str(n)) while self.response is None: self.connection.process_data_events() return int(self.response) fibonacci_rpc = FibonacciRpcClient() print ” [x] Requesting fib(30)”response = fibonacci_rpc.call(30)print ” [.] Got %r” % (response,) Код Клиента несколько сложнее:

  • (7) Мы устанавливаем соединение, канал и объявляем уникальную очередь результатов для полученных ответов;
  • (16) Мы подписываемся на очередь результатов для получения ответов от RPC;
  • (18) Функция обратного вызова 'on_response', исполнямая при получении каждого ответа, выполняет довольно тривиальную задачу — для каждого поступившего ответа она проверяет соответствует ли correlation_id тому что мы ожидаем. Если это так, она сохраняет ответ в self.response и прерывает цикл;
  • (23) Далее, мы определяем наш метод call, который, собственно, и выполняет RPC запрос;
  • (24) В этом методе мы сначала генерируем уникальный correlation_id и сохраняем его — функция обратного вызова 'on_response' будет использовать это значение для отслеживания нужного ответа;
  • (25) Далее мы помещаем запрос со свойствами reply_to и correlation_id в очередь;
  • (32) Далее начинается процесс ожидания ответа;
  • (33) И, в конце, мы возвращаем результат обратно пользователю.

Наш RPC сервис готов. Мы можем запустить сервер: $ python rpc_server.py [x] Awaiting RPC requests Для получения чисел Фибоначчи запускаем Клиент: $ python rpc_client.py [x] Requesting fib(30) Представленный вариант реализации RPC не является единственным возможным, но он имеет следующие преимущества:

  • Если RPC сервер слишком медленный, вы можете легко добавить еще один. Попробуйте запустить второй rpc_server.py в новой консоли;
  • На стороне Клиента, RPC требует отправки и получения только одного сообщения. Не требуется синхронный вызов queue_declare. Как результат, RPC клиент обходится одним циклом запрос-ответ для одного RPC запроса.

Наш код, тем не менее, является упрощенным и даже не пытается решать более сложные(но, безусловно, важные) проблемы вроде таких:

  • Как должен реагировать Клиент, если сервер не запущен?
  • Должен ли Клиент иметь таймоут для RPC?
  • Если Сервер в какой-то момент «сломается» и выбросит исключение, должно ли оно передаваться Клиенту?
  • Защита от недопустимых входящих сообщений(например, проверка допустимых границ) перед обработкой.

руководства

RabbitMQ tutorial 1 — Hello World (python)
RabbitMQ tutorial 2 — Очередь задач (python)
RabbitMQ tutorial 3 — Публикация/Подписка (php)
RabbitMQ tutorial 4 — Роутинг (php)
RabbitMQ tutorial 5 — Тематики (php)
RabbitMQ tutorial 6 — Удаленный вызов процедур (эта статья, python)

  • python
  • RabbitMQ
  • pika
  • amqp
  • rpc

Хабы:

  • Разработка веб-сайтов
  • Python
  • Программирование
  • 30 октября 2017 в 13:12
  • 7 ноября 2013 в 00:16
  • 6 ноября 2013 в 20:45

Источник: https://habr.com/ru/post/236221/

Удаленные вызовы процедур с запросом-ответом

Удаленный вызов процедур rpc как включить

Источник: Nuances of Programming

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

Я продемонстрирую реализацию RPC и расскажу о некоторых проблемах, с которыми мы столкнулись в работе.

Реализация RPC

Допустим, у нас есть заявка на заказ такси. Когда пользователь запрашивает такси, нужно рассчитать самый быстрый маршрут. Вычисление самого быстрого маршрута  —  сложная операция, и поэтому ее желательно переместить в отдельный сервис и потом масштабировать по мере необходимости. Этот сервис мы будем вызывать с помощью RPC.

Есть несколько вариантов реализации RPC. К примеру, через шаблон “запрос-ответ”. Этот шаблон реализуется с помощью брокера сообщений, например RabbitMQ.

Суть в том, что мы отправляем сообщение от клиента на сервер. Сервер отправит сообщение обратно клиенту, используя очередь ответов, которая была предоставлена в исходном запросе.

На следующем рисунке показано, как будет выглядеть такая реализация:

Пример реализации RPC с применением запроса-ответа

Чтобы выполнить удаленный вызов процедуры, сначала нужно создать новую очередь, откуда будет приходить ответ.

Каждому клиенту потребуется своя очередь ответов, и если клиент уже создал очередь ответов, он будет использовать ее повторно.

Можно также создать отдельную очередь для каждого запроса, однако эффективнее сопоставлять одну очередь только с одним клиентом.

Создав очередь, мы посылаем команду, в которой содержится значение CorrelationId и поле ReplyTo. Сервер примет это сообщение, обработает и отправит обратно другое сообщение с тем же CorrelationId. Это сообщение будет отправлено в очередь ответов, указанную в поле ReplyTo.

Когда клиент получит сообщение в очереди ответов, то с помощью CorrelationId сопоставит его с одним из своих ожидающих запросов.

Последнее, что придется сделать,  —  это убедиться, что сгенерированные очереди будут удалены, когда сервис завершит работу.

Обработка отказов

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

Может случиться так, что удаленный вызов процедуры не получит никакого ответа. Это может произойти в случае неработоспособности сервера. Чтобы предотвратить ?застревание клиента?, необходимо реализовать что-то вроде тайм-аута. Тайм-аут не должен быть долгим, так как пользователь ждет ответа.

Когда тайм-аут достигнут, мы вернем пользователю сообщение об ошибке. Таким образом, мы даем пользователю возможность повторить действие. Поскольку вычисление маршрута не имеет никаких побочных эффектов, нам не нужно будет беспокоиться о дублировании команд в случае повторной попытки.

Также запрос может просто не удаться. В этом случае нужно будет отправить сообщение обратно и подать клиенту сигнал. Здесь лучше не ждать достижения тайм-аута.

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

Вот некоторые преимущества такой реализации:

  • Масштабируемость. Конкретную услугу легко масштабировать, если расчет самого быстрого маршрута занимает много времени.
  • Сервис, который вычисляет самый быстрый маршрут, может быть оптимизирован для этой конкретной задачи.
  • Возможность ожидания ответа. Если что-то не удается, мы можем дать клиенту возможность повторить попытку.

Когда не следует применять RPC

Давайте рассмотрим несколько случаев, когда RPC лучше заменить иным подходом.

Долго выполняющиеся задачи

При выполнении удаленного вызова процедуры экземпляру придется ждать, пока он не получит ответ обратно. Запрос хранится в памяти, а это значит, что запрос окажется потерян, если экземпляр остановится.

Это может произойти при развертывании новой версии в рабочей среде. Когда мы развернем новую версию, старый экземпляр получит сигнал о том, что он должен корректно завершить работу. Он попытается перед этим завершить свой текущий запрос. Если сервисы не смогли этого сделать в течение нескольких секунд, то сервис будет вынужден прекратить работу.

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

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

Лучший способ справиться с этой задачей  —  отправить команду или событие и сохранить состояние запроса в хранилище данных. Когда задача будет выполнена, она отправит событие, которое мы можем прослушивать. Когда событие прибудет, мы получим запрос из хранилища данных и продолжим его обработку. При таком подходе не требуется, чтобы сообщение обрабатывалось одним и тем же экземпляром.

Цепочки RPC

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

Примеры проблем, которые могут возникнуть

Эти проблемы не относятся исключительно к цепочкам RPC, однако объединение нескольких служб в цепочку увеличивает вероятность возникновения указанных проблем, особенно если эти службы не отвечают в течение нескольких миллисекунд. Убедитесь, что при выполнении RPC через несколько служб такие случаи покрыты автоматическими повторными попытками.

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

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

Тем не менее, если все случаи сбоев обрабатываются правильно, то, безусловно, можно связать несколько сервисов в цепочку с RPC.

Действия, не подлежащие повторению

Будьте осторожны при применении RPC для действий, которые должны выполняться только один раз. Не всегда есть возможность узнать, была ли команда выполнена неудачно или успешно, когда достигнут тайм-аут. Кроме того, убедитесь, что службы, вызываемые с помощью RPC, корректно обрабатывают повторяющиеся команды.

Почему?

Потому что, когда мы запускаем удаленный вызов процедуры, сообщение отправляется в очередь. Если сообщение не будет обработано в течение заданного тайм-аута, клиент выдаст ошибку. Однако, когда сервис становится доступным, сообщение все еще будет находиться в очереди для обработки.

Пример повторяющихся сообщений в очереди сообщений

Это может создать проблему при выполнении однократно повторяющихся действий  —  таких как создание отчета или отправка письма по электронной почте.

Если вы действительно хотите использовать RPC таким образом, то следует реализовать механизм проверки, чтобы убедиться, что сообщение не обрабатывается раньше. Вы можете хэшировать содержимое запроса и хранить его в хранилище “ключ-значение”. При получении другого сообщения с тем же хэшем, его можно будет смело проигнорировать.

Послесловие

RPC  —  хороший подход до тех пор, пока все случаи сбоев обрабатываются правильно. Мне лично очень нравится следующее утверждение из учебника RabbitMQ:

«Если сомневаетесь, избегайте RPC».

Если ситуация будет подходящей для его применения, вы это поймете. Просто не забудьте рассмотреть и другие возможности.

Спасибо за чтение!

Источник: https://zen.yandex.ru/media/nuancesprog/udalennye-vyzovy-procedur-s-zaprosomotvetom-5fba93ed572b86257546ca22

Ошибка RPC: решается ли проблема без переустановки системы

Удаленный вызов процедур rpc как включить

Служба удалённого вызова процедур Windows (она же RPC или Remote Procedure Call) управляет протоколом, позволяющим программам выполнять свои действия на других компьютерах общей сети так же, как они выполнялись бы на данном компьютере — без необходимости разбираться в тонкостях подключения.

Протокол оказался очень удобным на практике: последние версии Windows используют его и для внутреннего взаимодействия программ, находящихся на одном устройстве. От его правильной работы зависят службы системного реестра, «Диспетчер устройств» и даже приложение File Explorer, отвечающее за корректное отображение системных окон и их свойств.

Что означает ошибка «Сбой при удалённом вызове процедуры»

Сбой при удалённом вызове процедуры происходит при отключении или повреждении службы RPC или других служб, от которых она зависит.

Ошибка была особенно распространена в 2015 году после выпуска некорректно работающего обновления Windows 10.

Сегодня такая ошибка практически наверняка означает конфликт установленных программ с стандартными программами пакета Windows 10 или повреждённые записи системного реестра, которые нам предстоит исправить.

Способы устранения ошибки «Сбой при удалённом вызове процедуры»

Убедимся для начала, что служба и все компоненты, на которые она полагается, включены и работают в штатном режиме. Затем попробуем убрать некоторые потенциальные программные несовместимости.

Проверка служб

Если сбой при удалённом вызове процедуры происходит на Windows 7, открываем список служб таким образом: «Пуск» → Выполнить → пишем services.msc, жмём Enter. В Windows 10 название службы можно ввести в строку поиска на Панели задач.

Откроется достаточно длинное окно служб, запущенных на компьютере. Нас интересуют четыре службы:

  • Удалённый вызов процедур (на английском служба будет называться «Remote Procedure Call (RPC)») — в статусе службы должна быть пометка «Работает», а тип запуска — «Автоматически». Если там стоит что-то другое, нажмите на строчку два раза — в появившемся окне будет возможность включить процедуру и выбрать автоматический тип загрузки. Если выставить значения не получается, проверьте сначала два следующих процесса ниже.
  • Модуль запуска процессов DCOM-сервера (DCOM Server Process Launcher) — должен быть включён, тип запуска «Автоматически».
  • Сопоставитель конечных точек RPC (RPC Endpoint Mapper) — аналогично.
  • Локатор удаленного вызова процедур (RPC) (Remote Procedure Call (RPC) Locator) — здесь тип запуска должен быть «Вручную».

Если вдруг что-то изменяем, перезагружаем компьютер и проверяем снова на наличие ошибки. Ошибка по-прежнему на месте или службы отказываются включаться? Попробуем поправить ситуацию через системный реестр.

Редактирование системного реестра

Редактор реестра открывается по тому же принципу, что и список служб, но написать нужно будет слово regedit. Находим там ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

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

В HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services вносим следующие поправки:

  • в подразделе DcomLaunch ищем ключ Start, щёлкаем на него два раза, выставляем значение 2;
  • в подразделах RpcEptMapper и RpcSs — аналогично;
  • в подразделе RpcLocator в ключе Start должно стоять значение 3.

Больше ничего не трогаем, сохраняем изменения и перезагружаем компьютер. Если проблема была связана с некорректным запуском служб, она исчезнет.

Проверка на несовместимость ПО

Если все службы работают как обычно (и не выключились сами после перезагрузки, проверьте), имеет смысл поискать и удалить несовместимое программное обеспечение.

Прежде всего — загрузитесь в безопасном режиме: откройте службу msconfig (через «Выполнить» или строку поиска, в зависимости от системы) и на вкладке «Загрузка» поставьте галочку на соответствующей опции.

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

В Windows 7 это осуществляется через всё ту же службу msconfig. В Windows 10, в принципе, можно зайти туда же, но вас перенаправят в Диспетчер задач, управляющий этой функцией на новой ОС. Диспетчер задач можно вызвать клавиатурной комбинацией Ctrl + Alt + Del.

Перейдите на вкладку «Автозагрузка» и уберите оттуда все программы. Затем добавляйте обратно по одной и перезагружайтесь после каждого добавления, пока не найдёте программу, провоцирующую конфликт.

Часто это бывают антивирусы и программы резервного копирования файлов (Comodo BackUp и т. п.).

Конфликтующие программы рекомендуется деинсталлировать или хотя бы использовать аналоги, не вызывающие проблем.

Проверка и ремонт системных файлов

Для решения проблем с системными файлами можно использовать утилиты SFC и DISM.

Откройте командную строку от имени администратора: «Пуск» → Стандартные → Командная строка (Windows 7) или введите cmd в строку поиска на Панели задач (Windows 10). Для запуска от имени администратора щёлкните на название программы правой кнопкой мыши и выберите соответствующую опцию контекстного меню.

В появившемся чёрном окне введите для начала:

sfc /scannow

Эта команда проверит основные системные файлы и попытается восстановить их, если увидит, что с ними что-то не так.

На Windows 10 доступна утилита DISM (Deployment Image Servicing and Management), позволяющая отремонтировать файлы, если вдруг не работает sfc.

На выбор есть две команды:

  • DISM /Online /Cleanup-Image /ScanHealth — проведёт сканирование системных файлов и доложит о возможных ошибках.
  • DISM /Online /Cleanup-Image /RestoreHealth — попытается эти ошибки исправить.

Вводим команды точно так же, как sfc, не забываем про пробелы перед каждым «/». После завершения ремонта — перезагружаемся.

Если «Сбой при удалённом вызове процедуры» возникает и здесь (обычно с кодом ошибки 1726) — проверьте, работают ли все службы RPC, как описано выше. Может также помочь временное отключение службы Windows Search.

Если ничего не помогает

Крайний вариант перед переустановкой системы — попробовать создать нового пользователя. В Windows 10 опция запрятана достаточно далеко: «Пуск» → Параметры → Учётные записи → Семья и другие пользователи.

Все системные настройки для нового пользователя будут выставлены по умолчанию, и конфликт ПО, если он был, исчезнет.

В Windows 7 пользователя можно создать здесь: «Пуск» → Панель управления → Учётные записи пользователей.

Если же проблема не исчезает даже на новой учётной записи, скорее всего, дело в дефекте RAM. Память можно проверить штатным средством Windows — службой mdsched. Проверка может занимать несколько часов. Ошибки памяти, если они есть, после проверки никуда не исчезнут: придётся сбрасывать «разгон», если что-то меняли, а в худшем случае — менять оперативную память.

Источник: https://nastroyvse.ru/opersys/win/sboj-pri-udalyonnom-vyzove-proczedury-windows.html

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.