diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita --- a/Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-50BE8F1A-513A-433C-B045-66658FC226D7.dita Tue Jul 20 12:00:49 2010 +0100 @@ -9,32 +9,36 @@ --> -Client/server -communication -

Inter Process -Communication (IPC) is the basis for client/server architecture. Clients -and servers run in different threads, although not necessarily in different -processes, and communicate through message passing protocol. There are no -direct pointers between the parties, leaving the integrity of the server and -its resources untouched by clients. For more information, see Introduction -to the client/server architecture.

-

Communication between the client and the server is managed by Inter-thread data transfer. -Only the server and its clients can decode the parameters of the message. -This is also a security feature, because process boundaries are separators -of memory space, direct pointers to the client's data structures cannot be -delivered. All data not fitting in the provided integers must be represented -as a descriptor, -and an address to the descriptor (or actually a TPckg object) -is delivered within the message. The server then uses safe inter-thread read -and write functions to access the provided descriptor.

+Client/server communication +

Inter +Process Communication (IPC) is the basis for client/server +architecture. Clients and servers run in different threads, although +not necessarily in different processes, and communicate through message +passing protocol. There are no direct pointers between the parties, +leaving the integrity of the server and its resources untouched by +clients. For more information, see Introduction to the +client/server architecture.

+

Communication between the client and the server is managed by Inter-thread data +transfer. Only the server and its clients can decode the parameters +of the message. This is also a security feature, because process boundaries +are separators of memory space, direct pointers to the client's data +structures cannot be delivered. All data not fitting in the provided +integers must be represented as a descriptor, and an address to the descriptor (or actually a TPckg object) is delivered within the message. +The server then uses safe inter-thread read and write functions to +access the provided descriptor.

The following figure shows the relationship of the TDesC and TPckg classes.

-Relationship of a message package and a descriptor class -

Consider the following issues when implementing the client-side API:

+Relationship of a message package and a descriptor class +

Consider the following issues when implementing the client-side +API:

    -
  • Determine if the server is already running with the TFindServer class. If not, then it should be launched.

  • -
  • Once the server is running, create the connection with RSessionBase::CreateSession and make sure there are free message slots available to avoid lost -messages.

  • -
  • When packaging message arguments, make sure they are in a -format that the server understands. For more information, see TIpcArgs.

  • +
  • Determine if the server is already running with the TFindServer class. If not, then it should be +launched.

  • +
  • Once the server is running, create the connection +with RSessionBase::CreateSession and make sure there +are free message slots available to avoid lost messages.

    +
  • +
  • When packaging message arguments, make sure they +are in a format that the server understands. For more information, +see TIpcArgs.

\ No newline at end of file