## 8 The C Server Back-end

### 8.1 Introduction

With the option `{be, c_server}` the IDL Compiler generates C server skeletons according to the IDL to C mapping, on top of the Erlang distribution and gen_server protocols.

The developer has to write additional code, that together with the generated C server skeletons, form a hidden Erlang node. That additional code contains implementations of call-back functions that implement the true server functionality, and also code uses `erl_interface` functions for defining the hidden node and for establishing connections to other Erlang nodes.

### 8.2 Generated Stub Files

The generated stub files are:

- For each IDL interface, a C source file, the name of which is `<Scoped Interface Name>__s.c`. Each operation of the IDL interface is mapped to a C function (with scoped name) in that file;
- C source files that contain functions for type conversion, memory allocation, and data encoding/decoding;
- C header files that contain function prototypes and type definitions.

All C functions are exported (i.e. not declared static).

### 8.3 C Skeleton Functions

For each IDL operation a C skeleton function is generated, the prototype of which is `int <Scoped Function Name>__exec(<Interface Object> oe_obj, CORBA_Environment *oe_env)`, where `<Interface Object>`, and `CORBA_Environment` are of the same type as for the generated C client stubs code.

Each `<Scoped Function Name>__exec()` function calls the call-back function

`<Scoped Function Name>_rs* <Scoped Function Name>__cb(<Interface Object> oe_obj, <Parameters>, CORBA_Environment *oe_env)`

where the arguments are of the same type as those generated for C client stubs.

The return value `<Scoped Function Name>_rs*` is a pointer to a function with the same signature as the call-back function `<Scoped Function Name>_cb`, and is called after the call-back function has been evaluated (provided that the pointer is not equal to `NULL`).

### 8.4 The Server Loop

The developer has to implement code for establishing connections with other Erlang nodes, code for call-back functions and restore functions.

In addition, the developer also has to implement code for a server loop, that receives messages and calls the relevant `__exec` function. For that purpose the IC library function `oe_server_receive()` function can be used.

### 8.5 Generating, Compiling and Linking

To generate the C server skeletons type the following in an appropriate shell:

`erlc -I ICROOT/include "+{be, c_server}" File.idl`,

where `ICROOT` is the root of the IC application. The `-I ICROOT/include` is only needed if `File.idl` refers to `erlang.idl`.

When compiling a generated C skeleton file, the directories `ICROOT/include` and `EICROOT/include`, have to be specified as include directories, where `EIROOT` is the root directory of the Erl_interface application.

When linking object files the `EIROOT/lib` and `ICROOT/priv/lib` directories have to be specified.

### 8.6 An Example

In this example the IDL specification file "random.idl" is used for generating C server skeletons (the file is contained in the IC `/examples/c-server` directory):

    module rmod {

      interface random {

        double produce();

        oneway void init(in long seed1, in long seed2, in long seed3);

      };

    };

Generate the C server skeletons:

    erlc '+{be, c_server}' random.idl
    Erlang IDL compiler version X.Y.Z

Six files are generated.

Compile the C server skeletons:

Please read the `ReadMe` file att the `examples/c-server` directory.

In the same directory you can find all the code for this example. In particular you will find the `server.c` file that contains all the additional code that must be written to obtain a complete server.

In the `examples/c-server` directory you will also find source code for an Erlang client, which can be used for testing the C server.

ic 4.2.13
Copyright © 1991-2007 Ericsson AB