home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 11 / 11.iso / n / n001 / 4.ddi / EXAMPLES / ASYNC / README
Encoding:
Text File  |  1989-09-14  |  9.5 KB  |  293 lines
  1.                        async Example
  2.  
  3.  
  4.  
  5.  
  6. 1.  Environment
  7.  
  8. This example is designed to be built and executed on a PC
  9. that runs DOS, the Watcom C Compiler and utilities, and that
  10. uses the NOVELL SPX network library.
  11.  
  12.  
  13.  
  14.  
  15. 2.  Overview
  16.  
  17. This example shows how to add custom code to an RPC
  18. specification so that the client can communicate
  19. asynchronously with the server.
  20.  
  21.  
  22.  
  23.  
  24. 3.  Keywords
  25.  
  26. asynchronous, non-blocking, Hooks, Traps, RPC macros,
  27. polling, import statement
  28.  
  29.  
  30.  
  31.  
  32. 4.  Files
  33.  
  34. Source files for this example reside in the following sub-
  35. directories:
  36.  
  37. server:
  38.  
  39.      Contains code and build procedures for the server part
  40.      of this distributed application.  The server consists
  41.      of the server control procedure, which is provided with
  42.      the product distribution, the dispatcher procedure and
  43.      server stub routines, which are generated by the RPC
  44.      Compiler, and the remote procedures, which are provided
  45.      with this example.
  46.  
  47.      rproc.c       remote procedure application code
  48.  
  49.      server.mk     makefile for building the server
  50.  
  51.      serv_def.h    include file with macro definitions for
  52.                    the server control procedure
  53.  
  54. client:
  55.  
  56.      Contains code and build procedures for the client part
  57.      of this distributed application.  The client consists
  58.      of the client main program and any associated routines,
  59.      which are provided with this example, and the client
  60.      stubs, which are generated by the RPC compiler.
  61.  
  62.      client.c      client application code (main program)
  63.  
  64.      client.mk     makefile for building the client
  65.  
  66. common:
  67.  
  68.      Contains the RPC interface specification used by the
  69.      RPC compiler to create the client and server stubs.
  70.      The RPC interface specification imports the
  71.      asynchronous RPC specification file to provide the
  72.      asynchronous interface.
  73.  
  74.      async.rpc     RPC interface specification for this
  75.                    example
  76.  
  77. async:
  78.  
  79.      Contains the RPC interface specification consisting of
  80.      client stub Hooks and Traps code and the source code
  81.      for poll_reply, which provide for an asynchronous
  82.      interface.
  83.  
  84.      async_i.rpc   asynchronous RPC specification and
  85.                    polling routine
  86.  
  87.      async_i.mk    makefile for building the asynchronous
  88.                    library and include file
  89.  
  90.      Note that the RPC Compiler is run only once with this
  91.      RPC specification file as input.  Generally, the
  92.      Compiler should be run with the file twice: once for
  93.      the client and once for the server, producing header
  94.      files and RPC code files for each.  However, for this
  95.      example the procedure is simplified because the single
  96.      header file produced can be used by both the client and
  97.      the server, the RPC Compiler is told to run in client
  98.      mode, and the only application code in the file is for
  99.      the client.
  100.  
  101.  
  102.  
  103.  
  104. 5.  Network Configuration
  105.  
  106. Before you can run this example, you may have to ask your
  107. system administrator to configure your system specifically
  108. for your needs.  The required configuration is described in
  109. the file: ..\..\READSPX
  110.  
  111.  
  112.  
  113.  
  114. 6.  Server Name
  115.  
  116. As distributed, the server for this example will register
  117. under the name "example".  However, it is strongly suggested
  118. that a unique server name be assigned to this example before
  119. it is built.
  120.  
  121. A unique server name will prevent two or more users from
  122. invoking a server process using the same server name.
  123. Choose a server name not likely to be selected by someone
  124. else.  For example, use your user or login name.
  125.  
  126. The server name must be changed in both the client and the
  127. server, and the SAME name must be used.  To change the
  128. server name for the client program, change to the client
  129. directory (client) and edit the file client.c.  Change the
  130. #define Server_Name statement as follows:
  131.  
  132.       #define Server_Name "example"
  133.           is changed to
  134.       #define Server_Name "myname"
  135.  
  136. To change the server name for the server program, change to
  137. the server directory (server) and edit the file serv_def.h,
  138. which contains the define statements for the server control
  139. procedure.  As with the client program, simply change the
  140. #define Server_Name statement.
  141.  
  142.  
  143.  
  144.  
  145. 7.  Building Client & Server
  146.  
  147. Procedures are included for building the example program.
  148. These procedures assume that your environment is set up as
  149. follows:
  150.  
  151.    - The PATH environment variable must specify the location
  152.      of the RPC Compiler executable files.
  153.  
  154.    - The LIB environment variable must specify the location
  155.      of the RPC runtime libraries.
  156.  
  157.    - The INCLUDE environment variable must specify the
  158.      location of the RPC .h include files.
  159.  
  160.    - The PDUDIR environment variable must specify the
  161.      location of the RPC .rpc files.
  162.  
  163.    - The RPCSCP environment variable must specify the
  164.      location of the RPC server control procedures.
  165.  
  166. The PATH, LIB, and INCLUDE environment variables should be
  167. set in your autoexec.bat file by modifying their current
  168. definitions. The PDUDIR and RPCSCP environment variables can
  169. be set in your autoexec.bat file, or in a local .bat file,
  170. or directly with the "set" command.
  171.  
  172. Since a distributed application runs on two machines, you
  173. must install an executable version of the client or server
  174. on another machine.  If the two machines are identical, you
  175. can build both executables (the client and server) on one
  176. machine and then move one of the executables.  However, if
  177. the two machines are not identical, you must follow the
  178. directions on the other machine for running this example and
  179. build one of the executable programs there (note that the
  180. executable filenames may differ across products).
  181.  
  182. To build the example program, you simply execute the build
  183. procedures in each subdirectory as follows:
  184.  
  185.   1.  Change to the async directory and build the files
  186.       associated with the imported RPC specification file:
  187.  
  188.            wmake /f  async_i.mk
  189.  
  190.   2.  Change to the client directory (client) and build the
  191.       client:
  192.  
  193.            wmake /f  client.mk
  194.  
  195.   3.  Change to the server directory (server) and build the
  196.       server:
  197.  
  198.            wmake /f  server.mk
  199.  
  200.  
  201.  
  202.  
  203.  
  204. 8.  Running the Distributed Application
  205.  
  206. The server program should be started before the client
  207. program is run.
  208.  
  209. To run the example on two machines, proceed as follows:
  210.  
  211.   1.  Change to the server directory (server) on the machine
  212.       running the server and start the server:
  213.  
  214.            server
  215.  
  216.   2.  Change to the client directory (client) on the machine
  217.       running the client and start the client:
  218.  
  219.            client
  220.  
  221.  
  222.  
  223.  
  224.  
  225. 9.  Description
  226.  
  227. This example demonstrates a client that uses a non-blocking
  228. RPC interface.  Using this interface, the client can
  229. generate an RPC request and continue executing until the RPC
  230. reply is returned by the server.  Once the reply is
  231. received, the client can then obtain the results returned by
  232. the remote procedure.
  233.  
  234. To facilitate the use of this style of asynchronous client
  235. interface, this example separates the non-blocking client
  236. code into a special RPC specification called "async_i.rpc."
  237. This RPC specification contains Hooks and Traps statements
  238. to customize client stubs so that they do not block for
  239. replies.  Thus, by importing "async_i.rpc" within an RPC
  240. specification, all client stubs generated from this
  241. specification provide an asynchronous client interface to
  242. the described remote procedures.
  243.  
  244. Once the client stubs have been customized to incorporate
  245. the asynchronous code, the client can call a client stub to
  246. generate a request and send this to the server.  Having
  247. initiated the remote procedure, the client stub returns to
  248. the client code so that this code can continue execution.
  249. Once the reply has been received, the client code can once
  250. again call the client stub.  This second call to the client
  251. stub receives the reply, unpacks the results, and returns
  252. these results to the client code.  To ensure that the
  253. results are handled properly, the client code must call the
  254. client stub twice with exactly the same parameters.
  255.  
  256. To assist in determining when the reply has been received,
  257. the "async_i.rpc" specification is accompanied by a library
  258. that contains a routine called poll_reply.  This routine is
  259. declared as follows:
  260.  
  261.      int poll_reply()
  262.  
  263. Whenever poll_reply is called, this procedure returns an
  264. integer value.
  265. A value of 1 means that a reply has been received; call the
  266. stub again with exactly the same parameters as before.
  267. A value of 0 means that a reply has not been received yet;
  268. continue as before, but do not call stub yet.
  269. An error code value means that an error was detected; call
  270. the stub again with exactly the same parameters as before so
  271. the state machine can clean up.
  272.  
  273. Using the poll_reply procedure, the client can determine
  274. when to call the client stub procedure again in order to
  275. handle the reply sent by the server.
  276.  
  277. Note that only one remote procedure call can be active
  278. waiting for a reply at any single point.  This restriction
  279. occurs because the code within this specification stores
  280. state information within a single global variable. See the
  281. async1 example for an example of how to give the client the
  282. capability of issuing multiple asynchronous remote procedure
  283. calls.
  284.  
  285. Further note that a server requires no special modifications
  286. to interact with an asynchronous client.  In fact, the same
  287. server may interact with both synchronous and asynchronous
  288. clients.
  289.  
  290. For more information on adding custom code, see the
  291. NetWare RPC User's Manual, Chapter 7, "Customizing the
  292. RPC Code."
  293.