Difference between revisions of "RPC Calls"
DavidWhitten (talk | contribs) (moved RPC Calls to VistA Imaging Issues/RPC Calls: Collect VistA Imaging notes together.) |
DavidWhitten (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | # | + | == Explanation == |
| + | |||
| + | RPC Calls are Remote Procedure Calls where a requesting application uses the network facilities to invoke a subroutine (or procedure). In most cases, the requesting application is running on a different machine than the serving application. In most cases, the serving application for the subroutine will get a request for a procedure, and other data which is needed by the procedure. The serving application will run the procedure and send the results back to the subroutine. | ||
| + | |||
| + | == Old RPC Broker overview == | ||
| + | |||
| + | Basically, for security, the old method of the RPC broker connection | ||
| + | was that your client PC would contact the RPC broker on a known port number. | ||
| + | The PC would send the RPC broker its own IP address. | ||
| + | Then the RPC broker on the server would start a proxy M job on the server | ||
| + | The proxy M job would create a new outgoing connection from the server to the | ||
| + | client using the IP address information sent originally by the client. | ||
| + | All communication between the Client application (such as CPRSChart) | ||
| + | and the server would then be handled on the new connection. | ||
| + | The client application would send [[FILE 8994|REMOTE PROCEDURE (File #8994)]] entry | ||
| + | names to the server-side proxy with parameter values. | ||
| + | The server-side proxy would look up the actual M code to run from the File, | ||
| + | add the parameter name for the result to be stored to the first of the call, and | ||
| + | collect the values of the parameters sent by the client over the TCP/IP connection | ||
| + | into local variables and use indirection (run time lazy evaluation) to call | ||
| + | the tag and routine (entry-reference) specified. After that subroutine finished, | ||
| + | the M proxy program would look at the type of entry in the [[FILE 8994|REMOTE PROCEDURE]] | ||
| + | file, and transmit the resulting values from the result parameter back over the | ||
| + | TCP/IP connection to the Client application. | ||
| + | This process of invoking Remote Procedure Calls continues. | ||
| + | Eventually, the client would send a request to close the RPC connection and | ||
| + | the proxy would execute a [[MUMPS COMMAND HALT|HALT]], freeing an M job slot. | ||
Latest revision as of 14:13, 21 March 2012
Explanation
RPC Calls are Remote Procedure Calls where a requesting application uses the network facilities to invoke a subroutine (or procedure). In most cases, the requesting application is running on a different machine than the serving application. In most cases, the serving application for the subroutine will get a request for a procedure, and other data which is needed by the procedure. The serving application will run the procedure and send the results back to the subroutine.
Old RPC Broker overview
Basically, for security, the old method of the RPC broker connection was that your client PC would contact the RPC broker on a known port number. The PC would send the RPC broker its own IP address. Then the RPC broker on the server would start a proxy M job on the server The proxy M job would create a new outgoing connection from the server to the client using the IP address information sent originally by the client. All communication between the Client application (such as CPRSChart) and the server would then be handled on the new connection. The client application would send REMOTE PROCEDURE (File #8994) entry names to the server-side proxy with parameter values. The server-side proxy would look up the actual M code to run from the File, add the parameter name for the result to be stored to the first of the call, and collect the values of the parameters sent by the client over the TCP/IP connection into local variables and use indirection (run time lazy evaluation) to call the tag and routine (entry-reference) specified. After that subroutine finished, the M proxy program would look at the type of entry in the REMOTE PROCEDURE file, and transmit the resulting values from the result parameter back over the TCP/IP connection to the Client application. This process of invoking Remote Procedure Calls continues. Eventually, the client would send a request to close the RPC connection and the proxy would execute a HALT, freeing an M job slot.
