configuration, cluster
This commit is contained in:
parent
5ab4db7caa
commit
034b1a789f
55
README.md
55
README.md
|
@ -42,12 +42,63 @@ eMQTT requires Erlang R17+.
|
|||
|
||||
## Configuration
|
||||
|
||||
......
|
||||
### etc/app.config
|
||||
|
||||
## Admin and Cluster
|
||||
```
|
||||
{emqtt, [
|
||||
{auth, {anonymous, []}}, %internal, anonymous
|
||||
{listen, [
|
||||
{mqtt, 1883, [
|
||||
{max_conns, 1024},
|
||||
{acceptor_pool, 4}
|
||||
]},
|
||||
{http, 8883, [
|
||||
{max_conns, 512},
|
||||
{acceptor_pool, 1}
|
||||
]}
|
||||
]}
|
||||
]}
|
||||
|
||||
```
|
||||
|
||||
### etc/vm.args
|
||||
|
||||
```
|
||||
|
||||
-sname emqtt
|
||||
|
||||
-setcookie emqtt
|
||||
|
||||
```
|
||||
|
||||
When nodes clustered, vm.args should be configured as below:
|
||||
|
||||
```
|
||||
-name emqtt@host1
|
||||
```
|
||||
|
||||
......
|
||||
|
||||
## Cluster
|
||||
|
||||
Suppose we cluster two nodes on 'host1', 'host2', steps:
|
||||
|
||||
on 'host1':
|
||||
|
||||
```
|
||||
./bin/emqtt start
|
||||
```
|
||||
|
||||
on 'host2':
|
||||
|
||||
```
|
||||
./bin/emqtt start
|
||||
|
||||
./bin/emqtt cluster emqtt@host1
|
||||
```
|
||||
|
||||
Run './bin/emqtt cluster' on 'host1' or 'host2' to check cluster nodes.
|
||||
|
||||
## HTTP API
|
||||
|
||||
eMQTT support http to publish message.
|
||||
|
|
|
@ -41,6 +41,13 @@
|
|||
|
||||
-type qos() :: ?QOS_2 | ?QOS_1 | ?QOS_0.
|
||||
|
||||
%%------------------------------------------------------------------------------
|
||||
%% MQTT Client
|
||||
%%------------------------------------------------------------------------------
|
||||
-record(mqtt_client, {
|
||||
client_id
|
||||
}).
|
||||
|
||||
%%------------------------------------------------------------------------------
|
||||
%% MQTT Message
|
||||
%%------------------------------------------------------------------------------
|
||||
|
|
|
@ -0,0 +1,32 @@
|
|||
# MQTT Protocol Guide
|
||||
|
||||
## Server or Broker
|
||||
|
||||
A program or device that acts as an intermediary between Clients which publish Application Messages and Clients which have made Subscriptions.
|
||||
|
||||
A Server Accepts Network Connections from Clients.
|
||||
Accepts Application Messages published by Clients.
|
||||
Processes Subscribe and Unsubscribe requests from Clients.
|
||||
Forwards Application Messages that match Client Subscriptions.
|
||||
|
||||
|
||||
Client ----> Broker(Server) ----> Client
|
||||
|
||||
Publisher ----> Broker -----> Subscriber
|
||||
|
||||
## Subscription and Session
|
||||
|
||||
### Subscription
|
||||
|
||||
A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single Session. A Session can contain more than one Subscription. Each Subscription within a session has a different Topic Filter.
|
||||
|
||||
### Session
|
||||
|
||||
A stateful interaction between a Client and a Server. Some Sessions last only as long as the Network
|
||||
|
||||
Connection, others can span multiple consecutive Network Connections between a Client and a Server.
|
||||
|
||||
## Topic Name and Filter
|
||||
|
||||
An expression contained in a Subscription, to indicate an interest in one or more topics. A Topic Filter can include wildcard characters.
|
||||
|
Loading…
Reference in New Issue