EMG 5.5.1 - User's Guide

Table of ContentsPreviousNextIndex

2. What's new in EMG 5.5

Below we list the the major new functionality in EMG 5.5.

The release includes database schema changes in tables "emguser" and "emguseraccess" and "emgd -upgradedb" needs to be run after updating EMG. Customers that are not using EMG together with MySQL are not affected by this.

2.1 IPV6 support

EMG now supports connections over IPV6. This resulted in a couple of user visible changes.

2.1.1 ADDRESS syntax

The hostname for the ADDRESS parameter can now be surrounded by "[" and "]". For IPV6 addresses which can contain ":" this is mandatory, since that character is used to separate the hostname and the port number. Examples:




For hostnames and addresses without ":", the old syntax ADDRESS=hostname:port is still supported.

2.1.2 Multiple interface support

After doing a DNS lookup, EMG previously only used the first address in the result set. Starting with version 5.5, all addresses are used, if possible. For an incoming connector, this means that if a host name resolves to both an IPV4 address and an IPV6 address, EMG will listen on both addresses. For an outgoing connector, EMG will try to connect to each address, one at a time.

For example: A host may have defined an IPV6 address as the first result. If the client machine or the network doesn't support IPV6, this connection will fail. If the host then has defined an IPV4 address as the second result, EMG will use that next.

2.1.3 Database schema changes

Previously EMG used the 32 bit numeric field ipaddress for the address. From version 5.5, there is also a new field "ipstr". The contents of this field should be a normal IPV4 or IPV6 address, such as or 1:2::3.

In the emguser table, a new column "lastipstr" is added, with the same format and contents as "ipstr" above.

New maximum value for database column "ipwidth".

Since an IPV6 address is 128 bits long, this is the new maximum value for the ipwidth column in the emguseraccess table.

These changes increases the schema number in emgsystem to 26.

2.2 Plugin API changes

2.2.1 Possible to change INSTANCES

It is now possible to change the number of threads used by a plugin, just as with connectors. Run "emgd -reload" to get the new value to take effect.

2.2.2 Modified parameter to thread_start()

Previously the second parameter to thread_start() was a pointer to a pluginq_t. This has now been changed to be a pointer to a http_pluginconfig_t. The old pointer is available as the field queue in that struct.

2.2.3 Reload logic

When running "emgd -reload", both C and Perl plugins are now reloaded. For efficiency, they are only reloaded if their time stamp has changed.

Afterwards, the new function after_reload() is called, once for each thread. This is necessary since each perl instance is running in a separate perl environment. The parameters to this function are the same as for all other after_* and before_* functions.

2.2.4 New plugin hook after_reload

Run once per thread (plugin instance).


It is now possible to implement a handler for incoming HTTP requests in perl, using URLHANDLER. The syntax is the same as for C:

CONNECTOR http-in <

Any number of URLHANDLER lines are allowed. They are completely independent, so you can even mix C and perl handlers if you want.

2.4 Custom connectors in Perl

Connectors with PROTOCOL=DLL can now be implemented in perl. The functions and parameters are the same as for the C API.

2.5 Improved HTTP transport driver

The C structure dll_encoder_arg_t has a few additional fields.

First the field timeout, which is the number of seconds that the read function should wait. By default it is 25 seconds.

The next field is smscop, an integer with the same meaning as the connector option SMSCOP. By default HTTP GET is used, but that can be changed to HTTP POST by setting smscop to 2.

The next field is httpdata, which is a pointer to a struct with type dll_http_request_t. It has 3 settable fields:

Name Type Default value Description

protocol int 11 The HTTP protocol, 10 for 1.0 and 11 for 1.1.

headers vbuf_t* "" Any additional HTTP headers

urldata vbuf_t* "" Any additional text to be added to the URL

With theses changes, most of the plugin specific transport functions should be possible to remove.

2.5.1 New transport_write2 and transport_read2 functions

The existing functions transport_write and transport_read only got the data pointer as parameter. To support the changes in the builtin HTTP driver, additional hooks transport_write2 and transport_read2 were added. As the second parameter they get a pointer to a dll_encoder_arg_t. In addition to the fields mentioned for the HTTP transport driver, this also makes it possible to set the forceclose and error parameters in that structure, which was previously done using int* parameters.

For perl, the old names transport_write and transport_read are used.

2.6 SMPP DLR handling

2.6.1 New option DLR_TEXT_FORMAT

The connector option DLR_TEXT_FORMAT takes a numeric parameter, and selects the format used for outgoing delivery reports on that connector.

Value Fields

0 id, sub, dlvrd, submit date, done date, stat:, err:, text:

1 id, submit date, done date, stat, err

2 id, submit date, done date, stat, err, text

3 id, submit date, done date, stat

4 id, submit date, done date, stat, text

5 id, sub, dlvrd, done date, stat, err

6 id, sub, dlvrd, done date, stat, err, text

2.6.2 New message option SMPP_DLR_TEXT

By setting this option from a plugin the text after "text:" in a SMPP delivery report can be customized.

In C:

    qe_option_replace(qe, MGP_OPTION_SMPP_DLR_TEXT, "dlr text");

In perl:

    $q->{'SMPP_DLR_TEXT'} = "dlr text";

2.6.3 New option SET_DLR_TEXT

If this connector option is set, the first 20 characters of the original message or the "text:" part of the incoming delivery report, is added as the "text:" part of the outgoing delivery report.

Table of ContentsPreviousNextIndex