<commit_before># Last Will and Testament Service

A possible Implementation could be using a backed queue on a broker at following address :

* $will

When the WS receives an AMQP_WILL message (see “Connection”), it puts this message into $will shared for all clients.

When the WS detects the link detaching from the FE (see “Disconnection”), it gets the message from $will using a “filter” on client-id (correlated with the detached link name)  and then publish it to the “will-topic”.

If WS crashes, on restart, it should get all messages from the $will queue and publish them. After, it should start a timer and if a client (which has a “will” in the queue) doesn’t reconnect in time, the “will” information will be deleted.

Another possible implementation could be using a backed queue on a broker for each client :

* $will.[client-id]

When the WS receives an AMQP_WILL message (see “Connection”), it puts this message into the right $will.[client-id] queue. The WS can receive the AMQP_WILL even during client life for overwriting the current one (or just adding it if the client didn’t provide will on connection).

When the WS detects the link detaching from the FE (see “Disconnection”), it gets the message from the right queue $will.[client-id] and then publish it to the “will-topic”.

If WS crashes, on restart, it should get all messages from the $will.[client-id] queues and publish them. After, it should start a timer and if a client (which has a “will” in its queue) doesn’t reconnect in time, the “will” information will be deleted.
<commit_msg>Updated information about LWTS implementation with API for storing/retrieving "will" information<commit_after># Last Will and Testament Service

## API

It's possible to define an API for interacting with something like an LWT Storage Service which can handle the underlying way for storing and retrieving "will" information.

This API is just made of basic CRUD (Create, Read, Update and Delete) operations :

* Create : for adding a "will" message of a new connected client
* Read : for getting the "will" message of a connected client
* Update : for updating the "will" message of a connected client
* Delete : for deleting the "will" message of a connected client

> The "Update" operation doesn't make sense in the MQTT space, because for this protocol "will" information can be provided only on connection. Updating "will" message is available for using this service with native AMQP clients where LWT feature doesn't exist by specification and is built on top of the raw protocol itself.

### Create

*Request*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| client-id | String | Client identifier (or link name) related to "will" information to store |
| will retain flag | Boolean | if the "will" is retained |
| will QoS level | Integer | QoS level for "will" publishing |
| will topic | String | Topic on which the "will" should be published |
| will message | Bytes | Payload of the "will" message |

*Response*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| response-code | Integer | Result for the requested operation |

### Read

*Request*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| client-id | String | Client identifier (or link name) related to "will" information to get |

*Response*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| response-code | Integer | Result for the requested operation |
| client-id | String | Client identifier (or link name) related to "will" information |
| will retain flag | Boolean | if the "will" is retained |
| will QoS level | Integer | QoS level for "will" publishing |
| will topic | String | Topic on which the "will" should be published |
| will message | Bytes | Payload of the "will" message |

### Update

*Request*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| client-id | String | Client identifier (or link name) related to "will" information to update |
| will retain flag | Boolean | if the "will" is retained |
| will QoS level | Integer | QoS level for "will" publishing |
| will topic | String | Topic on which the "will" should be published |
| will message | Bytes | Payload of the "will" message |

*Response*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| response-code | Integer | Result for the requested operation |

### Delete

*Request*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| client-id | String | Client identifier (or link name) related to "will" information to delete |

*Response*

| DATA | TYPE | DESCRIPTION |
| ---- | ---- | ----------- |
| response-code | Integer | Result for the requested operation |

A possible implementation could be just using a database for backing "will" messages.

## Interactions

When the LWTS receives an AMQP_WILL message (see “Connection”), it executes a "create" operation on the LWT Storage Service in order to store the "will" information for the new connected client.
If the AMQP_WILL message is received by an already connected client, the operation to be executed is an "update" for the "will" information already stored.

When the LWTS detects the link detaching from the GW (see “Disconnection”), it can do the following :

* if it's a clean detaching (no error), then a "delete" operation is executed against the LWT Storage Service just for deleting "will" information for the disconnected client because the "will" don't need to be published
* if it's a brute detaching (error), then a "read" operation is executed against the LWT Storage Service in order to get the "will" information for the disconnected client. Then, this information are used for building an AMQP_PUBLISH message to publish on the "will topic" and finally a "delete" operation is executed

If LWT service crashes, on restart, it should get all messages from the LWT Storage Service and publish them. After, it should start a timer and if a client (which has a “will” stored) doesn’t reconnect in time, the “will” information will be deleted.

{'fraction_non_alphanumeric': 0.09800995024875622, 'fraction_numerical': 0.0, 'mean_word_length': 3.678820791311094, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 4, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '669308', 'n_tokens_mistral': 1614, 'n_tokens_neox': 1523, 'n_words': 860}