Browse Prior Art Database

An asynchronous C interface for remote services Disclosure Number: IPCOM000124382D
Original Publication Date: 2005-Apr-18
Included in the Prior Art Database: 2005-Apr-18
Document File: 3 page(s) / 22K

Publishing Venue



A program interface is disclosed which provides a library that can be linked with a user's applications written in C. The abstraction provided by the interface is the set of services offered by another component (either on a remote node, a separate process, or a separate component within the same process).

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 3

An asynchronous C interface for remote services

This solution allows multiple operations to be performed in parallel, while minimizing the number of threads and memory used by the application.

The application opens a session with the component providing the services (the service component). The interface then establishes a connection with the service component, and starts one thread (a Read Thread) that listens for all responses to this application from the service component.

The proposed solution allows processes to run multiple tasks in parallel; providing an asynchronous interface via callback functions to minimize the number of threads used by the application (reducing memory and CPU usage).

When the application makes a request, a callback function is specified. The request assigned an ID that is used internally by the interface. The callback function is associated with the request ID, and the request is then sent to the service component.

Responses are picked up by the Read Thread that is started when the application opens a session through the interface. The user makes a request through the interface to some service provider. When responses are received from the service provider, the interface uses an internal request ID (which is returned with the response) to find the proper callback function. The callback function is used to return the response to the user.

The interface takes advantage of the fact that the solution is for a specific application domain by aggregating data and reducing communication costs. Events for example are grouped and sent together when appropriate.

This interface differentiates itself from other asynchronous interfaces for procedural languages in several ways:

The interface is simpler to use. There are no "handles" or "identifiers" for the using




application to maintain.

Consideration is given to memory and other resource constraints that exist in

products like Reef.

The remote calls are not inherently linked to specific methods that are known to the

user. Therefore, there is more flexibility in how the information is obtained, allowing remote calls to be aggregated and information relayed more efficiently.

Interfaces such as RMC use too many resources for an environment like Reef. RMC, as with this solution, is implemented in C++. However, the interface to RMC requires that a "handle" be returned to the user in place of the instantiated class in the underlying implementation.

Interfaces such as RMI, Corba, or RPC are inherently tied to specific methods. By disassociating the interface with the underlying implementation, we are able to provide


Page 2 of 3

increased performance and increased efficiency in resource usage (for example, higher bandwidth utilization by trying to send packets of optimal size).

The services interface is composed of an interface client and an interface server. The interface client is a library th...