Call remote procedures rpc ultrasound scanner. Remote procedure call mechanism - RPC

A very important mechanism for client-server applications is provided by RPC ( Remote Procedure Call). RPC was developed by Sun Micrsystems and is a collection of tools and library functions. In particular, NIS (Network Information System) and NFS (Network File System) work on RPC.

An RPC server consists of a system of such procedures that a client can access by sending an RPC request to the server along with the procedure parameters. The server will call the designated procedure and return the procedure's return value, if any. To be machine-independent, all data exchanged between client and server is converted to a so-called external data representation ( External Data Representation, XDR). RPC communicates with UDP and TCP sockets to transfer data in XDR format. Sun has declared RPC as a public domain, and its description is available in a series of RFC documents.

Sometimes changes in RPC applications introduce incompatibility into the interface call procedure. Of course, a simple change would cause the server to crash any applications that are still waiting for the same calls. Therefore, RPC programs have version numbers assigned to them, usually starting with 1. Each a new version RPC keeps track of the version number. Often the server may offer several versions at the same time. Clients in this case specify the version number they want to use.

The network communication between RPC servers and clients is a little special. An RPC server offers one or more system procedures, each set of such procedures is called a program ( program) and is uniquely identified by the program number ( program number). A list of service names is usually kept in /etc/rpc, an example of which is given below.

Example 12-4. Sample /etc/rpc file

In TCP/IP networks, the authors of RPC were faced with the task of mapping program numbers to common network services. Each server provides a TCP and UDP port for each program and each version. In general, RPC applications use UDP to transmit data and fall back to TCP when the data to be transmitted does not fit into a single UDP datagram.

Of course, client programs must have a way to figure out which port corresponds to the program number. Using a configuration file for this would be too inflexible; Since RPC applications do not use reserved ports, there is no guarantee that the port is not occupied by some application and is available to us. Hence, RPC applications choose any port they can receive and register it with portmapper daemon. A client that wants to contact a service with a given program number will first make a request to portmapper to find out the port number of the desired service.

This method has the disadvantage that it introduces a single point of failure, much like inetd daemon However, this case is a little worse because when the portmapper fails, all RPC information about the ports is lost. This usually means that you must restart all RPC servers manually or reboot the machine.

On Linux, the portmapper is called /sbin/portmap or /usr/sbin/rpc.portmap . Apart from the fact that it must be launched from the network startup script, portmapper does not require any configuration work.

Remote procedure call(or Calling remote procedures) (from English. Remote Procedure Call (RPC)) - a class of technologies that allow computer programs to call functions or procedures in another address space (usually on remote computers). Typically, an implementation of RPC technology includes two components: a network protocol for client-server communication and an object serialization language (or structures, for non-object RPC). Different RPC implementations have very different architectures and vary in their capabilities: some implement the SOA architecture, others CORBA or DCOM. At the transport layer, RPCs primarily use TCP and UDP protocols, however, some are built on top of HTTP (which violates the ISO/OSI architecture, since HTTP is not a transport protocol natively).

Implementations

There are many technologies that provide RPC:

• Sun RPC (binary protocol based on TCP and UDP and XDR) RFC-1831 second name ONC RPC RFC-1833
• .Net Remoting (binary protocol based on TCP, UDP, HTTP)
• SOAP - Simple Object Access Protocol (HTTP-based text protocol) see specification: RFC-4227
• XML RPC (HTTP based text protocol) see specification: RFC-3529
• Java RMI - Java Remote Method Invocation - see specification: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (HTTP-based text protocol) see specification: RFC-4627
• DCE/RPC - Distributed Computing Environment / Remote Procedure Calls (binary protocol based on various transport protocols, including TCP/IP and Named Pipes from the SMB/CIFS protocol)
• DCOM - Distributed Component Object Model known as MSRPC Microsoft Remote Procedure Call or "Network OLE" (an object-oriented extension to DCE RPC that allows you to pass references to objects and call object methods through such references)

Principle

The idea of ​​a Remote Procedure Call (RPC) is to extend the well-known and understood mechanism for transferring control and data within a program running on one machine to transfer control and data over a network. Remote procedure call tools are designed to facilitate the organization of distributed computing and the creation of distributed client-server information systems. The greatest efficiency of using RPC is achieved in those applications in which there is interactive communication between remote components with fast response times and a relatively small amount of data transferred. Such applications are called RPC-oriented.

Implementing remote calls is much more complicated than implementing local procedure calls. We can identify the following problems and tasks that need to be solved when implementing RPC:

• Because the calling and called procedures run on different machines, they have different address spaces, and this creates problems when passing parameters and results, especially if the machines are running different operating systems or have different architectures (for example, little-endian or big-endian). ). Since RPC cannot rely on shared memory, this means that RPC parameters must not contain pointers to non-stack memory locations and that parameter values ​​must be copied from one computer to another. To copy procedure parameters and execution results over the network, they are serialized.
• Unlike a local call, a remote procedure call necessarily uses the transport layer of the network architecture (for example, TCP), but this remains hidden from the developer.
• The execution of the calling program and the called local procedure on the same machine is implemented within a single process. But the implementation of RPC involves at least two processes - one on each machine. If one of them crashes, the following situations may arise: if the calling procedure crashes, the remotely called procedures will become “orphaned”, and if the remote procedures crash, the calling procedures will become “destitute parents”, which will wait in vain for a response from the remote procedures.
• There are a number of problems associated with the heterogeneity of programming languages ​​and operating environments: the data structures and procedure call structures supported in any one programming language are not supported in the same way in all other languages. Thus, there is a compatibility problem that has not yet been solved either by the introduction of one generally accepted standard, or by the implementation of several competing standards on all architectures and in all languages.

Subsystems

• Transport subsystem

Manage outgoing and incoming connections. - support for the concept of “message boundary” for transport protocols that do not directly support it (TCP). - support for guaranteed delivery for transport protocols that do not directly support it (UDP).

• Thread pool (callee only). Provides an execution context for code invoked over the network.

• Marshalling (also called "serialization"). Packing call parameters into a byte stream in a standard way, independent of the architecture (in particular, the order of bytes in a word). In particular, it can affect arrays, strings, and structures pointed to by pointer parameters.

• Encrypting packages and applying a digital signature to them.

• Authentication and authorization. Transmission over the network of information identifying the subject making the call.

In some RPC (.NET Remoting) implementations, subsystem boundaries are open polymorphic interfaces, and it is possible to write your own implementation of almost all of the listed subsystems. In other implementations (DCE RPC on Windows) this is not the case.

see also

Remote Procedure Call (RPC) Remote Procedure Call Concept

The idea of ​​a Remote Procedure Call (RPC) is to extend the well-known and understood mechanism for transferring control and data within a program running on one machine to transfer control and data over a network. Remote procedure call tools are designed to facilitate the organization of distributed computing. The greatest efficiency of using RPC is achieved in those applications in which there is interactive communication between remote components with fast response times and a relatively small amount of data transferred. Such applications are called RPC-oriented.

The characteristic features of calling local procedures are:

• Asymmetry, that is, one of the interacting parties is the initiator;
• Synchronicity, that is, the execution of the calling procedure is suspended from the moment the request is issued and is resumed only after the called procedure returns.

Implementing remote calls is much more complicated than implementing local procedure calls. To begin with, since the calling and called procedures are executed on different machines, they have different address spaces, and this creates problems when passing parameters and results, especially if the machines are not identical. Since RPC cannot rely on shared memory, this means that RPC parameters must not contain pointers to non-stack memory locations and that parameter values ​​must be copied from one computer to another. The next difference between RPC and a local call is that it necessarily uses the underlying communication system, but this should not be explicitly visible either in the definition of the procedures or in the procedures themselves. Remoteness introduces additional problems. The execution of the calling program and the called local procedure on the same machine is implemented within a single process. But the implementation of RPC involves at least two processes - one on each machine. If one of them crashes, the following situations may arise: if the calling procedure crashes, the remotely called procedures will become “orphaned”, and if the remote procedures crash, the calling procedures will become “orphaned parents”, waiting in vain for a response from the remote procedures.

In addition, there are a number of problems associated with the heterogeneity of programming languages ​​and operating environments: the data structures and procedure call structures supported in any one programming language are not supported in the same way in all other languages.

These and some other problems are solved by the widespread RPC technology, which underlies many distributed operating systems. Basic Operations RPC

To understand how RPC works, let's first consider making a local procedure call on a typical machine running offline. Let this be, for example, a system call

count=read(fd, buf, nbytes);

where fd is an integer, buf is an array of characters, nbytes is an integer.

To make the call, the calling procedure pushes the parameters onto the stack in reverse order (Figure 3.1). After the read call is executed, it places the return value into a register, moves the return address, and returns control to the calling procedure, which pops parameters from the stack, returning it to its original state. Note that in the C language, parameters can be called either by reference (by name) or by value (by value). In relation to the called procedure, value parameters are initialized local variables. The called procedure can change them without affecting the original values ​​of these variables in the calling procedure.

If a pointer to a variable is passed to the called procedure, then changing the value of this variable by the called procedure entails changing the value of this variable for the calling procedure. This fact is very significant for RPC.

There is also another mechanism for passing parameters that is not used in C. It is called call-by-copy/restore, which requires the caller to copy variables onto the stack as values, and then copy them back after the call is made over the original values ​​of the calling procedure.

The decision about which parameter passing mechanism to use is made by the language developers. Sometimes it depends on the type of data being transferred. In C, for example, integers and other scalar data are always passed by value, and arrays are always passed by reference.

Application

A significant part of the instruments remote control The Windows operating system (Event Viewer, Server Manager, print management, user lists) uses DCE RPC as a means of communication over the network between the managed service and the user interface control application. DCE RPC support has been present in Windows NT since the very first version 3.1. DCE RPC clients were also supported in the light line operating systems Windows 3.x/95/98/Me.

The Windows system libraries that provide such control capabilities and serve as the base layer for user interface control applications (netapi32.dll and partly advapi32.dll) actually contain client code for the DCE RPC interfaces that perform this control.

This architectural decision was the subject of active criticism against Microsoft. The generic marshalling procedures present in DCE RPC are very complex and have a huge potential for defects to be exploited in the network by sending a deliberately malformed DCE RPC packet. A significant part of the defects Windows security, discovered from the late 90s to the mid-2000s, were precisely errors in the DCE RPC marshalling code.

In addition to DCE RPC, Windows actively uses DCOM technology. For example, it is used as a means of communication between IIS web server management tools and the server itself being managed. A fully functional interface for communicating with the MS Exchange Server mail system - MAPI - is also based on DCOM.

The idea of ​​calling remote procedures (Remote Procedure Call - RPC) consists of extending the well-known and understood mechanism for transferring control and data within a program running on one machine to transferring control and data over a network. Remote procedure call tools are designed to facilitate the organization of distributed computing.

The greatest efficiency of using RPC is achieved in those applications in which there is interactive communication between remote components With short response time And relatively small amount of transmitted data.Such applications are called RPC-oriented.

The characteristic features of calling local procedures are:

asymmetry, that is, one of the interacting parties is the initiator;

Synchronicity, that is, execution of the calling procedure is suspended from the moment the request is issued and resumed only when the called procedure returns.

Implementing remote calls is much more complicated than implementing local procedure calls.

1. Let's start with the fact that since the calling and called procedures are executed on different machines, they have different address spaces, and this creates problems when transferring parameters and results, especially if the machines are not identical.

Since RPC cannot rely on shared memory, this means that RPC parameters must not contain pointers to non-stack memory locations So what parameter values ​​must be copied from one computer to another.

2. The next difference between RPC and a local call is that it necessarily uses the underlying communication system, however this should not be clearly visible either in the definition of procedures or in the procedures themselves .

Remoteness introduces additional problems. Executing the calling program and the called local procedure on the same machine implemented withinsingle process. But involved in the implementation of RPCat least two processes - one in each car. If one of them fails, the following situations may occur:

If the calling procedure crashes, the remotely called procedures will become "orphaned" and

If remote procedures terminate abnormally, the calling procedures will become "destitute parents" and wait for a response from the remote procedures to no avail.

In addition, there is a number of problems associated with the heterogeneity of programming languages ​​and operating environments : Data structures and procedure call structures supported in any one programming language are not supported in the same way in all other languages.

These and some other problems are solved by the widespread RPC technology, which underlies many distributed operating systems.

The idea behind RPC is to make a remote procedure call look as similar as possible to a local procedure call. In other words, make RPC transparent: the calling procedure does not need to know that the called procedure is on another machine, and vice versa.

RPC achieves transparency in the following way. When the called procedure is actually remote, another version of the procedure, called a client stub, is placed in the library instead of the local procedure. Like the original procedure, the stub is called using a calling sequence (as in Figure 3.1), and an interrupt occurs when accessing the kernel. Only, unlike the original procedure, it does not place parameters in registers and does not request data from the kernel; instead, it generates a message to be sent to the kernel of the remote machine.

Rice. 3.2. Remote Procedure Call

The purpose of this article is to discuss terminology. The article is not about how and why, but only about the use of terminology. The article reflects the opinion of the author and does not pretend to be scientific.

Introduction

If you work in programming distributed systems or in systems integration, then most of what is presented here is not new to you.

The problem comes when people who use different technologies meet, and when those people start having technical conversations. In this case, mutual misunderstandings often arise due to terminology. Here I will try to bring together the terminologies used in different contexts.

Terminology

There is no clear terminology and classification in this area. The terminology used below is a reflection of the author’s model, that is, it is strictly subjective. Any criticism and any discussions are welcome.

I've divided the terminology into three areas: RPC (Remote Procedure Call), Messaging and REST. These areas have historical roots.

RPC

RPC technologies - the oldest technologies. The most prominent representatives of RPC are - CORBA And DCOM.

In those days, it was mainly necessary to connect systems in fast and relatively reliable local networks. The main idea behind RPC was to make calling remote systems much like calling functions within a program. The entire mechanics of remote calls were hidden from the programmer. At least they tried to hide it. Programmers in many cases were forced to work at a deeper level, where the terms marshaling appeared ( marshalling) And unmarshalling(how is that in Russian?), which essentially meant serialization. Normal function calls within processes were handled at the caller's end in Proxy, and on the side of the system performing the function, in Dispatcher. Ideally, neither the calling system nor the processing system would deal with the intricacies of transferring data between systems. All these subtleties were concentrated in the Proxy - Dispatcher bundle, the code of which was generated automatically.

So you won't notice, you shouldn't notice, any difference between calling a local function and calling a remote function.
Now there is a kind of RPC renaissance, the most prominent representatives of which are: Google ProtoBuf, Thrift, Avro.

Messaging

Over time, it turned out that the attempt to protect the programmer from the fact that the called function still differs from the local one did not lead to desired result. The implementation details and fundamental differences between distributed systems were too great to be resolved using automatically generated Proxy code. Gradually, the understanding came that the fact that the systems are connected by an unreliable, slow, low-speed environment must be explicitly reflected in the program code.

Technologies have appeared web services. We started talking ABC: Address, Binding, Contract. It is not entirely clear why contracts appeared, which are essentially Envelopes for input arguments. Contracts often complicate the overall model rather than simplify it. But... it doesn't matter.

Now the programmer explicitly created service(Service) or client(Client) calling the service. The service consisted of a set operations (Operation), each of which took at the input request(Request) and issued answer(Response). Client explicitly sent(Sent) request, the service explicitly received ( Receive) and answered him (Sent), sending the answer. The client received a response and the call ended.

Just like in RPC, there was a Proxy and Dispatcher running somewhere. And as before, their code was generated automatically and the programmer did not need to understand it. Unless the client explicitly used classes from Proxy.

Requests and responses are explicitly converted to a format intended for transmission over the wire. Most often this is a byte array. The transformation is called Serialization And Deserialization and sometimes hides in the Proxy code.
The culmination of messaging manifested itself in the emergence of the paradigm ESB (Enterprise Service Bus). No one can really articulate what it is, but everyone agrees that data moves through the ESB in the form of messages.

REST

In the constant struggle with code complexity, programmers took the next step and created REST.

The main principle of REST is that function operations are sharply limited and left only a set of operations CRUD: Create - Read - Update - Delete. In this model, all operations are always applied to some data. The operations available in CRUD are sufficient for most applications. Since REST technologies in most cases imply the use of the HTTP protocol, the CRUD commands were reflected in the commands HTTP (Post - Get - Put - Delete) . It is constantly stated that REST is not necessarily tied to HTTP. But in practice, reflection of operation signatures onto the syntax of HTTP commands is widely used. For example, calling the function

EntityAddress ReadEntityAddress(string param1, string param2)

Expressed like this:

GET: entityAddress?param1=value1¶m2=value2

Conclusion

Before starting a discussion on distributed systems or integration, define the terminology. If Proxy will always mean the same thing in different contexts, then, for example, request will mean little in RPC terms, and marshalling will cause confusion when discussing REST technologies.

After rebooting the computer the service did not start" Remote Procedure Call (RPC)". A lot depends on this service. As a result, system recovery, network environment, sound, Windows Installer do not work, the management console (MMC) almost does not work, open windows are not shown on the taskbar, etc., etc. An attempt to manually start results in the error " Cannot start...(RPC) on xxxComp. Error 5: Access denied"The antivirus found nothing. Two days of digging and the computer was brought back to life.

According to Microsoft's recommendation, the first thing I tried was to find and delete the registry key . I didn’t have it, perhaps as a result of some installed updates.

Next, an attempt to restore the service parameters in the registry. Since regedit.exe was read/delete only (another side effect), it was not possible to make changes. Yes, they were not needed, because... everything was right. It should look like this:

Windows Registry Editor Version 5.00 "Description"="Provides mapping of endpoints and other RPC services." "DisplayName"="Remote Procedure Call (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\\NetworkService" "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 "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 "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 "0"="Root\\LEGACY_RPCSS\\0000" "Count"=dword:00000001 "NextInstance"=dword:00000001

Parameter value start may vary. You can still change the registry, but you need to boot from MS ERD commander.

I’ll simply describe the next steps point by point. The general idea is that you need to replace the files with ones that are known to work. They can be taken from another machine or from a Windows distribution (as I did).

• Launch the console (Start > Run: cmd)
• cd z:\i386(Windows distribution there)
• expand explorer.ex_ %TEMP%\explorer.exe
• expand svchost.ex_ %TEMP%\svchost.exe
• Launch Task Manager (Ctrl+Shift+Esc)
• Stop exlporer.exe process
• copy %TEMP%\explorer.exe %SYSTEMROOT% /y
• Stop all svchost.exe processes. Attention! After this, you will have 60 seconds until the machine reboots.
• copy %TEMP%\svchost.exe %systemroot%\system32 /y

This feint also did not produce results. Another option: run a scan of all protected system files with replacement wrong versions correct. In the console run:

It didn’t help.. Then a completely brutal move is to restore the security settings. Again in the console:

After rebooting the computer started working basic services started. A new problem appeared (or maybe it was there from the very beginning): at least Disk Management Manager and Windows Installer did not start under my account. Access denied. You can restore access rights to the system disk to the “default” via the console:

Then you need to manually define the rights for each account. or recreate them, whichever is easier.

In my case, I simply assigned the same rights to the entire system disk, using access to the . I added my domain account to the standard with full rights to the disk. Maybe this is wrong from a security point of view, but I don’t have time to delve into each directory separately.

What else could be done

While the computer was sick, this was not in the registry:

"ActiveService"="RpcSs"

Perhaps manual addition would somehow change the situation.

Attempts to manually start the service, for example through the command " net start rcpss"ended in error" Error 5: access denied". I assume access is denied because the service must be launched under the system account - "NT AUTHORITY". There is the following parameter in the registry:

"ObjectName"="NT AUTHORITY\\NetworkService"

I would try to enter the admin account here and start the service again. But this is only an idea that did not live up to implementation.

Another option: use the KiTrap0D exploit to obtain a console with system rights. This exploit was written about in . Actually a binary. But I have Windows updates, so it looks like this exploit no longer works.

Related materials: