documentation

Community Messaging Project (CMP)

To communicate humanly between IRC, portal websites and gameservers or even more.

Architecture

Meta ...

Example ...

The IRC bots

Historically, the IRC bots were first. :)

Eggdrop Bot TCL plugin

Channel and ban configuration from a webserver simple XML (yikes anyhow)

• Can act as standalone community IRC messaging service (CIMS)
• expands itself with eggdrop botnet ability
• expands itself with the messaging service and control server

It provides the following commands on the messaging service: Link

Standalone Go-Lang Bot

Configuration from a webserver YAML

It provides the following commands on the messaging service: Link

The gameserver joining bots

A gameserver joining bot joins the gameservers by whatever means the gameserver protocol allows and then allows commands to be used by users to interact with other people.

QuakeWorld Bot

The current QuakeWorld Bot connects to the quakeworld (qw) gameservers that are defined in its configuration file. It is able to connect to nearly unlimited qw servers. But be sure to have a look at the cpu strain it will get on the server.

It also connects to the control server via SSH to send and receive network commands.

• Can act as standalone QuakeWorld Bot community messaging
• Expands itself with the messaging service and control server

It provides the following commands on the messaging service: Link

The portal websites

PHP Client

A php client written by Sni is also available but kinda unmaintained. It is in use by quakeworld.nu. It connects to the control server by SSH to read and write network messages.

Link

The Control Server

The "Control Server" merely is a client on the messaging service. But since it is the portion that actually helps forming processes between the other clients, we began calling it "Server". Generally it allows for more interaction between the various kinds of clients.

So it defines a minimal set of text protocol under which the other clients can talk to each other and even provides some simple services to, for example, resolve IP addresses to nice short names and countries.

It provides the following commands on the messaging service: Link

The transport layer

Every client connects (or can connect) to a messaging service where they can interact with the other clients. It is the communication backbone. So to say, it's the transport layer of the messages with which the programs interact. Let's say 'message transport' and 'messaging service' are synonyms and 'network commands' are the commands that clients chose to provide and request on each other within the Community Messaging Project.

As a future (late 2017?) underlying message transport I chose NATS from Apcera. https://nats.io

At the very moment (since 2014), the whole message transport is done via a ruby server that works together with a SSH-Server to send and receive messages. It is nicely working but there we have a single point of failure. There is only one Server that all clients have to connect to. We need this more scalable and failsafe.

Have a look at the quakeworld community. We provide and use this IRC broadcasting service now for over a decade. It sure works, but this community is a golden nugget in comparison to many other communities. It deserves an even better working service which they can expand and code on.

Resiliency of program message transport

Communities change and people come and go. So do servers and all those moving parts of a networked program. Lets make it more resilient.

You can join the whole network by adding a cluster node to the messaging service. This would then extend the messaging service to make it more resilient. This also means, the communication between all clients would be working in all those conditions when a server fails. The clients would still find a messaging server inside the cluster. See https://nats.io for clustered NATS.

Even more, lets say, if the whole NATS portion of the network fails, clients would still need to be able to connect to the network. So, we could - in some unknown future - even add Amazon Web Services Simple Queuing Service (SQS) to this network by coding a gateway from NATS to SQS. But that's future talk for something that was never meant THIS big. ;-) Let's dream.

Final words

This messaging service has been in use in the quakeworld community now for over a decade, dating back to 2002. Let's keep it alive and expandable.