Messaging overview

Let us examine two entities (client and server) that have an IPC channel established between them. Let cl be the client IPC handle of this channel while sr is the server IPC handle of this channel.

The code provided below is intended to demonstrate the IPC mechanism. System calls are not normally used directly in entity code. To allow a convenient exchange of messages, special NK-generated methods are provided, which use system calls.

Client entity code:

client.c

…

// Get the client IPC handle cl using Service Locator

…

// Send request

Call(cl, &RequestBuffer, &ResponseBuffer);

…

Server entity code:

server.c

…

// Get the server IPC handle sr using Service Locator

…

// Receive request

Recv(sr, &RequestBuffer);

…

// Process request

…

// Send response

Reply(sr, &ResponseBuffer);

…

Messages are exchanged as follows:

  1. One of the client threads executes the Call() system call, passing as arguments the cl handle (client handle of the utilized channel), the pointer to the buffer containing the request message, and the pointer to the buffer for the response.
  2. The request message is sent to Kaspersky Security System to be checked. If Kaspersky Security System returns an "allowed" decision, we proceed to step 3. Otherwise, the Call() is terminated with the rcSecurityDisallow error code, and we proceed to step 9.
  3. If the server is waiting for a request from this client—i.e. the server has executed the Recv() call, passing sr as the first argument—we proceed to step 4. Otherwise, the client thread remains locked until one of the server threads executes a Recv() system call with the first sr argument.
  4. The request message is copied to the address space of the server. The server thread is unlocked, and the Recv() call is terminated with an rcOk code.
  5. The server processes the received message. The client thread remains locked.
  6. The server executes the Reply() system call, passing as arguments the sr handle and the pointer to the buffer with the response message.
  7. The response message is sent to Kaspersky Security System to be checked. If Kaspersky Security System returns an "allowed" decision, we proceed to step 8. Otherwise, the Call() and Reply() calls are terminated with an rcSecurityDisallow error code (see step 3).
  8. The response message is copied to the address space of the client. The server thread is unlocked, and the Reply() call is terminated with an rcOk code. The client thread is unlocked, and the Call() is terminated with an rcOk code.
  9. The exchange is complete.

If an error occurs when sending the request (insufficient memory, invalid message format, etc.), the threads are unlocked and the Call() and Reply() calls return an error code.

Page top