Messaging Server

1 Requirements

For the new version ILIAS 5.1 it is planned to redevelop the Chat-Server-Component.
This development is structured in three core components.
 

• Realtime
• Scalability
• Easyier administration

1.1 Realtime

The current version of the chatserver uses short-polling for message transfer. In this method the client sends a request to the chat server in fixed time interval. The chatserver responds to this request, whether or not there are new messages to transfer. This is a problem because the messages are not delivered in realtime. If the chatserver reveives a new message between 2 requests, the message has to be stored in the chatserver as long as it is called by a new poll request from a chatclient.
As mentioned, the chat server will also responds to a request if there are no messages stored. This produces a huge amount of unnecessary traffic which could be avoided by using modern technologies.

To get rid of these problems, we will implement a new communication method called Websockets. Websockets allow a persistent connection between client and server after a successful TCP-Three-Way-Handshake. After the initial connection the server is able to push new messages directly to the client without any additional requests taking place. This enables realtime communication, because there is no need to store message for a period of time in the server. Additionally, data is only transferred to the client, if the server has messages waiting.

Websockets are only availabe in modern browser versions. To address the problem of legacy browsers accessing the system, we will implement a fallback called Long-polling. In comparison to short-polling it is still required that the client sends frequent requests to the server, but the server closes the connection only if it has messages to deliver. If there are no messages waiting, the connection will be kept open until a new message is received. Then the new messsage will be sent to the client and the connection will be closed. In contrast to short-polling the client will not wait for a fixed time interval to reopen a connection, it rather sends a new request directly after the old one has been completed. With this method the number of requests and responses is reduced enormously.

1.2 Scalability

With the new implementation we face to create higher scalability behaviour of the server-component. The administator should be able to configure one chat-server for multiple ILIAS-clients. This is very useful for smaller ILIAS-installations with only a few number of concurrent active users. This also improves the workload of one chat-server.
 
Furthermore it is planed to use multiple chat-servers for only one ILIAS-client. If there are ILIAS-clients with a large userbase it can be possible, that the server is not able to handle all the connection. For that the administrator shall be able to configure parallel chat-servers in one ILIAS-installation. The concret amount of workload of a server has to be determined while the development. If an administrator has configures multiple servers and the amount of possible workload for one server is reached, the connections will be balanced through all known servers. However all users will be able to communicate with each other, no matter what server they are connected to.

1.3 Easier administrations

Very often, ILIAS is used behind a Proxy-Server. The configuration of chat-server using a proxy-server is very challenging for most administrators. Therefore, the configuration will be adjusted to be much easier. This adjustment will be further carved out in close collaboration with experienced administrators who configure chat-servers on a regular basis. The core idea is to setup multiple IP's that are used by diffrent components to communicate with each other.

Implementation
 
It should be discussed how the new version of the chat-server will be implemented. The current version is developed in Java. But according to the hugh knowledge base in JavaScript and PHP it would be interessting to use modern architectures like nodeJs (JavaScript) or Rachet (PHP) for implementing the chat-servers. Especially nodeJS has been proven by many developers in Websockets based messenger implementation for webbrowsers.
After a few testing the implementation using nodeJS seems much smoother and maintainable in comparison to a Java based chat server.

May 13, 2015: In communication with Ralf Schenk we determined that security/certificate handling can be improved by using noteJs. PKCS12 Certificates are supported and Ciphers options can be set to mitigate BEAST Attacks. A configuration of the chat could look like:

1
2
3
4
5
6
7
8
9
10
11
12
13

var options = {
    host: 'example.com',
     path: '/',
    headers: headers,
    method: 'GET',
    key: fs.readFileSync('resources/keys/privateKey.pem'),
    cert: fs.readFileSync('resources/keys/publicCert.pem'),
    passphrase: 'secret123',
    agent: false,
    rejectUnauthorized: false
};
 
options.agent = new https.Agent(options);

The certification file paths could be configured in an configuration file.

For more information about TLS and Ciphers read:

• https://nodejs.org/api/tls.html
• http://www.developerdave.co.uk/2014/10/two-way-ssl-node-js/

2 Additional Information

• Idea / concept:
• Maintainer: Jansen, Michael [mjansen] /
• Implementation of the feature is done by Databay AG AG, 
• Test cases by / status: (name, e-mail), (status information set after implementation)

3 Discussion

AT 2015-04-10: We really need this to be implemented for the learning communities. 

JF 27 Apr 2015: We appreciate the feature and schedule it for 5.1.

• We drop IE9 support for this feature, if anyone wants to support IE9 additional funding may be needed.
• We prefer to have all chat data in the ILIAS DB, please try to make a rough estimation on the additional effort needed (also check if a ilServer integration could be feasible here).
• In general both nodeJS (please check thread safety) or Java based solutions would be ok for us.
• Please check if security/certificate handling can be improved for administrators.
• Even if the chat server is a separate entity, all source code should be put into the ILIAS Git repository and be licensed under GPLv3.

JourFixe, ILIAS [jourfixe], August 31, 2015: We still appreciate this feature and schedule it for 5.2. Implementation shall be done with nodeJS.

4 Implementation

Jansen, Michael [mjansen] August, 17th 2016: According to the JF decision the chat server implementation was done with Node.js . The communication between client (browser) and server (Node.js) is done via HTML5 WebSockets (see: Browser Support of HTML5 WebSockets).
During the implementation phase we also fixed several issues in the repository object chat user interface and replaced the invitation dialogue with a boostrap modal.

The chat server component requires network access to the ILIAS database (similar to the ilServer).

Test Cases

Test cases completed at August 1, 2016 by Matuschek, Nadia [nadia]:

• C7179: Chatraum anlegen
• C7180: Chatraum betreten
• C7184: Chatnachricht abschicken
• C7185: Chatnachricht mit Emoticon verschicken
• C12826: Einzelnen User mit Chatnachricht ansprechen
• C12827: Private Chatnachricht an einzelnen User
• C12828: Séparée anlegen
• C12829: User in Séparée einladen
  
• C12830: Séparée verlassen
  
• C12831: Séparée löschen
  
• C12832: Anderen Chatraum / Séparée betreten
• C12833: Tageshistorie anzeigen
  
• C12834: Sitzungshistorie anzeigen
  
• C12835: Info
  

Approval

Version 1.0 approved at 01.04.2016 by  Tesche, Uwe [utesche] .