About COID

Features

• The generator tool (coidgen) generates everything needed for remote method invocation on objects of given class. It uses additional keywords in the declaration of class to produce both client-side wrapper and server-side dispatcher. Additional control keywords, defined as empty preprocessor symbols, are used to mark the direction of method parameters (in, out, inout) and desired access modes.

• Any types can be used for method arguments, given that they don't collide with the parameter direction. Actual arguments are transfered using abstract stream class binstream. This stream class has specializations for network tcp and udp streams, file and memory streams, encoding and text formatting stream wrappers and more. To be able to use a custom type in the parameters of class methods, one must write just the << and >> operators from this type to (and from) binstream.
  

• COID implements versioning of classes it exposes. There can exist multiple versions of the same class (service) and the server correctly detects incompatibilities and links together the right versions of client and dispatcher. The generator automatically detects changes to definition of methods and updates the version accordingly.
  

• Server automatically detects whether the client is on the same machine or even in the same process, and chooses optimal connection - interprocess communication or direct binding of client to server-side implementation. The direct method binding is equivalent to virtual method calls (with mutex locking). Instantiation of service classes can be determined by required access mode (remote/interprocess/direct).
  

• Network frontend for tcp connections. Objects can be created when the framework receives a new connection at specified network port. Object will be called to process the connection. The objects will be reused for connectionless (one-shot) requests and created on the fly if needed.

• Transparent http tunneling of the COID protocol, with support for proxy.
  

• Remote admin console. The console service itself is implemented as COID-extended object (a service). Since the COID objects in the remote mode communicate using abstract binstream class, the console service utilizes txtparstream specialization of binstream to be able to create objects from the console, bind to existing objects, call objects methods etc. The text stream adapter converts input and output data to text on the fly without objects (service instances) even knowing that they have been called from console.
  

Screenshot of an example class declaration decorated with coid keywords:




Features in development

XML Gateway - COID served C++ classes will be usable directly as backend servers for AJAX technique applications. Currently there's a simple http service that is used for http tunneling. We are extending this service and adding metastream capabilities to coid/comm library, for COID to serve as a gateway for XMLHttpRequest calls from browsers. No special handling required by your code, a XMLHttpRequest call will get translated directly to a method call.

In-browser console - Using the AJAX technique, a web application that connects to the coid server and allows to inspect the server and services, create and destroy managed objects, call methods of running services and so on.

Interfaces - in addition to default 'interface' exposed by the class (all its methods form the default class interface), a specific interface (a subset) can be implemented by the service and requested from a client. The interface is defined as a virtual base class, extended with COID-required keywords. Applications or other services can bind to various different objects using one interface client class, given that the objects implement the interface.

Access specifiers - a client may be given different interface in dependence on authentification or application specific processing. For example, client that authentifies itself as anonymous can be given interface with only the read-only methods (const methods in class) present. The methods that modify the object (non-const ones) are replaced with universal method that either returns or throws ersDENIED error object. This works for both direct and remote access. What methods are accessible in the interface can be determined not only by the const-ness, but also by custom flags. Generally, method is accessible in the client if the authentified client has all flags set that are specified as required for accessing the method.