* Adopt channel architecture and improve the MQTT frame parser
* Update the test cases for emqx_channel, emqx_protocol
- Improve emqx_client to Use the new emqx_frame:parse/2
- Update the ct suites for emqx_channel, emqx_ws_channel
* Fix test case
Prior to this change, the arguments passed to gen_statem:reply is bad
args, first arg should be a tuple, but it is a pid. So it would
trigger crash.
This change fix this bug.
* Delete response_topic_prefix
The Response-Infomation in CONNACK was misinterpreated, it should
not be a broker's global config, instead, it should be per-client
or even per-session prefix/suffix mechanism
* Delete request-response code from emqx_client
* Add request-response test code
* meck as default dependency --- temp workaround for dep-vsn-check
Prior to this change, if a emqx_client:publish/? caller sends in
QoS=1/2 messages too fast, emqx_client may return
`{error, inflight_full}` which could put put the caller to an
awkward situation: there seem to be no ohter option except for
putting self to a sleep-n-retry infinite loop.
In this change, a new gen_statm state 'inflight_full' is introduced
as a sub-state of 'connected'. When emqx_client is in 'inflight_full'
state, it postpone all publish calls (for QoS=1/2) until inflight
window size shrinks.
In this commit, msg_handler option is added to emqx_client.
so the caller can provide callbacks to handle puback, publish,
as well as disconnected events instead of always delivered
as message like Owner ! {publish, Msg} to the owner process.
This is to make it ready to implement emqx_portal_connect on
top of emqx_client.
* Fix the Exit in testcases
* Fix Exit in emqx_mod_sup_SUITE
* Update testcases for log_tracer
* Fix Exit in emqx_protocol_SUITE
* Add will_acl_check
* Fix more Exits
Prior to this change, emqx_client:start_link does 2 works in one call:
- init an erlang process for emqx_client
- send MQTT CONNECT to remote broker
But this solution have some drawbacks:
- the return value of `start_link` compiles the return values of the 2
works: {ok, Pid, MqttResult}. It is inconsistent with the return value
of `gen_statem:start_link`, may causes confusions.
- the return mode of the 2 works are different:
`start_link` should always return {ok, Pid} or {error, Reason}, but
connecting to mqtt may throw out exceptions as it handles the
socket. But the caller couldn't have thought of the exception, he would
pattern match on the result of `emqx_client:start_link`, but it crashed!
- If the init work succeed but the connection failed, the caller couldn't
get a Pid from the return value, but indeed it was created inside the
emqx_client. This hides the fact that the Pid was created, and when the
Pid dies, the caller would receive an message from a Pid it doesn' know about.
This change divived these 2 work into 2 APIs:
- `start_link/1` is to build and verify the options, and returns {ok,Pid}
(on success) or {error, Reason} (on failure).
- `connect/1` is to send MQTT CONNECT, and returns {ok, MQTTResult::properties()} or
{error, MQTTReason}. MQTT reason codes will contains in the `MQTTReason`.
Add request & response support for CONNECT & CONNACK
Prior to this change, there is no validate and specified process for
Request-Response-Information and Response-Information
Also added basic Request/Response functionality to emqx_client implementation
When a controlling process starts multiple clients that make multiple
subscriptions it may be desirable to identify from which client a
message is comming from. The topic id may not be sufficient.
terry-xiaoyu