diff options
Diffstat (limited to 'TAO/examples/Content_Server/AMI_Observer/README')
| -rw-r--r-- | TAO/examples/Content_Server/AMI_Observer/README | 70 |
1 files changed, 5 insertions, 65 deletions
diff --git a/TAO/examples/Content_Server/AMI_Observer/README b/TAO/examples/Content_Server/AMI_Observer/README index f9e4de33b5d..8c5d635dcb2 100644 --- a/TAO/examples/Content_Server/AMI_Observer/README +++ b/TAO/examples/Content_Server/AMI_Observer/README @@ -14,66 +14,7 @@ is as follows: * The CORBA Naming Service is used to bind and resolve object references, rather than using a file. - - -Basic design of the programs: - -The basic idea used in both the client and and the server is to use -AMI when performing all requests. This allows both the client and the -server to perform other tasks without having to wait for a given task -to complete. - -The client first activates its Callback object, and then -asynchronously registers a reference to its Callback object with the -server's Push_Iterator_Factory. The Push_Iterator_Factory then -creates an AMI reply handler "Callback_Handler" for the requested file -that asynchronously sends chunks of data to the client's Callback -object. After creating and running the Callback_Handler, the -Push_Iterator_Factory returns the Metadata containing the content type -and modification date of the file to client. Since the Callback was -registered using the Push_Iterator_Factory using AMI, an AMI reply -handler called "Push_Iterator_Handler" on the client side will receive -and handle the Metadata returned from the Push_Iterator_Factory. The -Push_Iterator_Handler then passes the received Metadata to the -Callback object. The Callback will spawn an external viewer once both -the Metadata and the entire file content have been received. The -Callback object is designed to correctly handle the case where the -content is received before the Metadata, and vice versa. This -operation is thread-safe. Note that no threads are created at the -application level in neither the client nor the server, yet -concurrency is still achieved due to the fact that AMI is used on both -sides. - -A schematic of the operations involved follows: - - CLIENT SERVER - ------ ------ - Push_Iterator_Handler - activate - Callback - activate Push_Iterator_Factory - activate - - sendc_register_callback() ---> register_callback() - Callback_Handler - activate - - next_chunk() <--- sendc_next_chunk() - . . - . . - . . - next_chunk() <--- sendc_next_chunk() - - register_callback() <--- Metadata - returned - Metadata passed to Callback - - next_chunk() <--- sendc_next_chunk() - . . - . . - . . - next_chunk() <--- sendc_next_chunk() - -Note that the Callback_Handler will not send the next chunk until it -receives a reply from the client's Callback object. This ensures that -the client receives all chunks of data in the proper order. - - + The client program performs the following activities: 1. From the command-line, it reads the name of the pathname @@ -84,10 +25,10 @@ The client program performs the following activities: object reference for a CosNaming::NamingContext interface, which is then used to resolve the object reference that the server bound earlier. After narrowing this to the Server - interface, the sendc_register_callback() operation is - called via the object reference to pass asynchronously pass - the Callback interface from the client to the server, which - then uses AMI to push chunks of the file to the client. + interface, the register_callback() operation is called via + the object reference to pass the Callback interface from + the client to the server, which then uses AMI to push + chunks of the file to the client. 2. The server calls the sendc_next_chunk() method on the callback, passing in the offset and the next chunk. @@ -99,7 +40,6 @@ The client program performs the following activities: viewer is spawned to display the file. The type of viewer to spawn is determined by examining the the content_type_ metadata returned by the server. - The example can be run as follows: |