Previous Next Table of Contents

3. How to set up a service

3.1 Compile time option for the server

First of all, it is important to note that in order to be able to connect a service to a server, this server must have been compiled with ``USE_SERVICES'' defined in the config.h file. To know if your server has been compiled with this option, check the version:

351 Server 2.9.3. AaCeEFiIkMu$_V1

351 Server 2.9.3. AaeEFHiKMpstuYZ_V1

Here, only ``'' was compiled with the ``USE_SERVICES'' defined as the lowercase ``s'' shows in the version string.

As they are special clients, services need to be allowed access to the server in the configuration file. Each service needs its own access to be setup. This is gone by adding an S: line to the configuration file. This lines defines the name of the service, as well as the type.

3.2 Glossary

Services have two main characteristics:


This is a misleading name. The type is actually a bit mask which defines what information the service can see. The server configuration file limits the type allowed for a service. The meaning of the bits is defined in the service.h file coming with the IRC software:

SERVICE_WANT_SERVICE    0x00000001 /* other services signing on/off */
SERVICE_WANT_OPER       0x00000002 /* operators, included in umodes too */
SERVICE_WANT_UMODE      0x00000004 /* user modes, iow + local modes */
SERVICE_WANT_AWAY       0x00000008 /* away isn't propaged anymore.. */
SERVICE_WANT_KILL       0x00000010 /* KILLs */
SERVICE_WANT_NICK       0x00000020 /* all NICKs (new user, change) */
SERVICE_WANT_USER       0x00000040 /* USER signing on */
SERVICE_WANT_QUIT       0x00000080 /* all QUITs (users signing off) */
SERVICE_WANT_SERVER     0x00000100 /* servers signing on */
SERVICE_WANT_WALLOP     0x00000200 /* wallops */
SERVICE_WANT_SQUIT      0x00000400 /* servers signing off */
SERVICE_WANT_RQUIT      0x00000800 /* regular user QUITs (these which
                                   are also sent between servers) */
SERVICE_WANT_MODE       0x00001000 /* channel modes (not +ov) */
SERVICE_WANT_CHANNEL    0x00002000 /* channel creations/destructions */

SERVICE_WANT_ERRORS     0x01000000 /* &ERRORS */
SERVICE_WANT_LOCAL      0x04000000 /* &LOCAL */



This controls the propagation of the service. The distribution is checked against server names, the service will only be on servers which names matches the distribution.

It also eventually limits the information received by the service (depending on the service type). A service will not have any information concerning users or services connected to a server which name does not match the distribution.


Using a server name as distribution makes the service local to the particular server.


This would match any server in the toplevel ``fr''.


This is the distribution to be used to make the service global.

It is important to note that the path between the service and a server must be composed of servers which have matching names: <----> <----->
       ^  ^
       |  |
       |  +------>
       +-------[MyService - Distribution *.no]
As shown above, if two ``*.no'' servers have a non ``*.no'' (for example here a ``*.fi'') server connected between them, in this case the information related to ``MyService'' will not propagate to ``''.

This means that the service will see information concerning the ``3 *.no'' servers, but ``'' will have no knowledge of the presence of ``MyService''. Also, the service is unable to send anything thru ``''.

3.3 Signing on as a service

Once the S: line setup on the server, the service connects by sending the password (PASS command), and then issuing a ``SERVICE'' command:

SERVICE servicename servername distribution servicetype 0 :Information


This is the name of the service as configured by the S line.


This is ignored by the server.


This is the distribution mask for this connection.


This is the service type as configured by the S line. (It must match)


This is any information. It will be sent in ``SERVLIST'' replies and should be a short description of the service.

A successfull registering of a service at the server will result in a RPL_YOURESERVICE (383) being sent back to the service. Any other reply as a result of sending service indicates an error has occured.

3.4 Requesting data from the server

Once the connection is established, the service needs to issue a ``SERVSET'' command to receive the data it wants:

SERVSET mask1 mask2


It is a subset of the service type. It defines what the kind of information the service wants to receive for this particular connection.

This mask can also have the following bits set, regardless of what the S line setting is:

SERVICE_WANT_PREFIX     0x10000 /* to receive n!u@h instead of n */
SERVICE_WANT_TOKEN      0x20000 /* use server token instead of name */
SERVICE_WANT_EXTNICK    0x40000 /* user extended NICK syntax */


It is optional. It is a subset of mask1 that defines which information the service wants to receive in a ``connection burst''. The information is similar to a server ``connection burst'', it describe the current set of the network. The service can therefore store the information in memory and update it.


The ``SERVSET'' command can only be issued once.

Previous Next Table of Contents