ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਤੋਂ ਬਿਨਾਂ ESP8266 ਕੰਟਰੋਲ: MQTT ਦਾ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਰਾਹ

ਉਪਕਰਣ ਘਰ ਦੇ ਰਾਊਟਰ ਪਿੱਛੇ ਹੈ, ਕੋਈ ਪੋਰਟ ਫਾਰਵਰਡਿੰਗ ਨਹੀਂ ਅਤੇ ਕੋਈ ਜਨਤਕ ਪਤਾ ਨਹੀਂ, ਫਿਰ ਵੀ ਇਸ ਨੂੰ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੈ। ਚਾਲ ਫਾਇਰਵਾਲ ਵਿੱਚ ਮੋਰੀ ਨਹੀਂ ਹੈ। ਇਹ ਉਹ ਕਨੈਕਸ਼ਨ ਹੈ ਜੋ ਉਪਕਰਣ ਬਾਹਰ ਵੱਲ ਉਸ ਬ੍ਰੋਕਰ ਵੱਲ ਖੋਲ੍ਹਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਬ੍ਰੋਕਰ ਫਿਰ ਉਸੇ ਸਥਾਪਿਤ ਰਾਹ ਰਾਹੀਂ ਸੁਨੇਹੇ ਵਾਪਸ ਭੇਜਦਾ ਹੈ। ਇਸ ਡਿਜ਼ਾਈਨ ਵਿੱਚ ਲੋਕਾਂ ਨੂੰ ਪਸੰਦ ਆਉਣ ਵਾਲਾ ਹਰ ਗੁਣ ਅਤੇ ਇਸ ਵਿਚਲੀ ਹਰ ਜਾਲ ਇਸੇ ਉਲਟਫੇਰ ਤੋਂ ਆਉਂਦੀ ਹੈ।

NAT ਵਿੱਚੋਂ ਅਸਲ ਵਿੱਚ ਕੀ ਲੰਘਦਾ ਹੈ

ਜਦੋਂ ਉਪਕਰਣ ਬ੍ਰੋਕਰ ਨਾਲ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦਾ ਹੈ, ਘਰ ਦਾ ਰਾਊਟਰ ਇੱਕ ਮੈਪਿੰਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਪ੍ਰਵਾਹ ਦੀ ਉਮਰ ਭਰ ਇਸ ਨੂੰ ਜੀਵਤ ਰੱਖਦਾ ਹੈ। ਉਸ ਪ੍ਰਵਾਹ ਦੇ ਜਵਾਬ ਉਪਕਰਣ ਕੋਲ ਵਾਪਸ ਆਉਂਦੇ ਹਨ ਕਿਉਂਕਿ ਮੈਪਿੰਗ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ। ਬ੍ਰੋਕਰ ਕਦੇ ਵੀ ਘਰ ਵੱਲ ਕੁਝ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਰਾਊਟਰ ਨੂੰ ਰੱਦ ਕਰਨ ਵਾਲਾ ਕੋਈ ਬਿਨਾਂ ਮੰਗਿਆ ਆਉਣ ਵਾਲਾ ਪੈਕਟ ਨਹੀਂ ਹੈ। ਇਹੀ ਪੂਰੀ ਨੈੱਟਵਰਕਿੰਗ ਦਲੀਲ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਇਹ ਤਰੀਕਾ ਉਨ੍ਹਾਂ ਨੈੱਟਵਰਕਾਂ ਉੱਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਨਿਯੰਤਰਿਤ ਨਹੀਂ ਕਰਦੇ।

ਉਪਕਰਣ ਨੂੰ ਕਨੈਕਸ਼ਨ ਜੀਵਤ ਰੱਖਣਾ ਹੈ ਜਾਂ ਦੁਬਾਰਾ ਸਥਾਪਿਤ ਕਰਨਾ ਹੈ, ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਤੈਅ ਹੋਣ ਤੋਂ ਬਾਅਦ ਇਹੀ ਭਰੋਸੇਯੋਗਤਾ ਦਾ ਸਵਾਲ ਬਣ ਜਾਂਦਾ ਹੈ।

ਬ੍ਰੋਕਰ ਵਿਸ਼ਿਆਂ ਨੂੰ ਰੂਟ ਕਰਦਾ ਹੈ, HTTP ਨੂੰ ਪ੍ਰੌਕਸੀ ਨਹੀਂ ਕਰਦਾ

MQTT ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਗਾਹਕੀ ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ: ਉਪਕਰਣ ਉਸ ਵਿਸ਼ਾ ਫਿਲਟਰ ਦੀ ਗਾਹਕੀ ਲੈਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਉਸ ਨੂੰ ਇਜਾਜ਼ਤ ਹੈ, ਅਤੇ ਅਧਿਕਾਰਤ ਕੰਟਰੋਲਰ ਮੇਲ ਖਾਂਦੇ ਵਿਸ਼ੇ ਉੱਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਬ੍ਰੋਕਰ ਪ੍ਰਕਾਸ਼ਨਾਂ ਨੂੰ ਗਾਹਕੀਆਂ ਨਾਲ ਮਿਲਾਉਂਦਾ ਹੈ ਅਤੇ ਨਕਲਾਂ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇਸ ਨੂੰ ਨਹੀਂ ਪਤਾ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਬੇਨਤੀ ਕੀ ਹੈ, ਅਤੇ ਇਹ ਉਪਕਰਣ ਦੇ ਵੈੱਬ ਸਰਵਰ ਉੱਤੇ HTTP GET ਨਹੀਂ ਭੇਜੇਗਾ। ਜੇ ਮੌਜੂਦਾ ਫਰਮਵੇਅਰ ਸਿਰਫ਼ HTTP ਬੋਲਦਾ ਹੈ, ਤਾਂ ਬ੍ਰੋਕਰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਐਪਲੀਕੇਸ਼ਨ ਬਦਲਾਅ ਜਾਂ ਜਾਣਬੁੱਝ ਕੇ ਬਣਾਇਆ ਅਨੁਵਾਦ ਭਾਗ ਚਾਹੀਦਾ ਹੈ।

ਵਿਸ਼ਿਆਂ ਦੇ ਨਾਮ ਵੀ ਅਧਿਕਾਰ ਨਹੀਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਬ੍ਰੋਕਰ ਹਰ ਕਲਾਇੰਟ ਲਈ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਸੂਚੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਉਪਕਰਣਾਂ ਨੂੰ ਇੱਕ ਵਿਸ਼ਵਵਿਆਪੀ ਨਾਮ ਸਥਾਨ ਸਾਂਝਾ ਕਰਨ ਦੀ ਥਾਂ ਆਪਣੇ ਪ੍ਰਕਾਸ਼ਨ ਅਤੇ ਗਾਹਕੀ ਰੁੱਖਾਂ ਤੱਕ ਸੀਮਿਤ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਉਪਕਰਣ ਦੇ ਸਰੋਤ TLS ਦਾ ਰੂਪ ਤੈਅ ਕਰਦੇ ਹਨ

ESP8266 ਵਿੱਚ ਸੀਮਿਤ RAM ਹੈ, ਅਤੇ TLS ਹੈਂਡਸ਼ੇਕ ਇਸ ਦਾ ਸਭ ਤੋਂ ਮਹਿੰਗਾ ਕੰਮ ਹੈ। Arduino ਕੋਰ BearSSL ਠੀਕ ਇਸੇ ਸੀਮਾ ਲਈ ਦਿੰਦਾ ਹੈ, ਅਤੇ CA ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਅਤੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਪਿੰਨ ਕਰਨ ਵਿਚਕਾਰ ਚੋਣ ਮੈਮੋਰੀ ਦੇ ਨਿਸ਼ਾਨ ਅਤੇ ਦੂਜੇ ਨਾਮ ਲਈ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਵਾਲੇ ਹਮਲਾਵਰ ਦੇ ਕੰਮ ਦੋਵਾਂ ਨੂੰ ਬਦਲਦੀ ਹੈ। ਜਦੋਂ ਹੀਪ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਤਾਂ ਬ੍ਰੋਕਰ ਦਾ CA ਪੁਸ਼ਟੀ ਕਰਨਾ ਵਧੇਰੇ ਮਜ਼ਬੂਤ ਵਿਕਲਪ ਹੈ। ਪੇਲੋਡ ਦਾ ਆਕਾਰ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ: MQTT ਕਲਾਇੰਟ ਇੱਕ ਬਫਰ ਰੱਖਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਡੇ ਸੁਨੇਹੇ ਬਫਰ ਜਾਣਬੁੱਝ ਕੇ ਵਧਾਏ ਬਿਨਾਂ ਚੁੱਪਚਾਪ ਕੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ।

ਕੀਪਅਲਾਈਵ ਅਤੇ ਸਾਕਟ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਇੱਕੋ ਬਜਟ ਦਾ ਹਿੱਸਾ ਹਨ, ਕਿਉਂਕਿ ਮਰੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਕਦੇ ਨਾ ਵੇਖਣ ਵਾਲਾ ਕਲਾਇੰਟ ਬਿਨਾਂ ਗਲਤੀ ਦੱਸੇ ਹੁਕਮ ਲੈਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ।

ਡੰਗਣ ਵਾਲੀ ਸੁਨੇਹਾ-ਅਰਥਸ਼ਾਸਤਰ

ਰੱਖਿਆ ਹੋਇਆ ਸੁਨੇਹਾ ਬ੍ਰੋਕਰ ਸੰਭਾਲਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਮੇਲ ਖਾਂਦੇ ਗਾਹਕਾਂ ਨੂੰ ਦਿੰਦਾ ਹੈ, ਜੋ ਮੌਜੂਦਾ ਸਥਿਤੀ ਲਈ ਸ਼ਾਨਦਾਰ ਅਤੇ ਇੱਕ-ਵਾਰੀ ਹੁਕਮਾਂ ਲਈ ਖਤਰਨਾਕ ਹੈ: ਦੁਬਾਰਾ ਜੁੜਨ ਵਾਲਾ ਉਪਕਰਣ ਕੱਲ੍ਹ ਦਾ ਹੁਕਮ ਨਵਾਂ ਸਮਝ ਕੇ ਲੈ ਸਕਦਾ ਹੈ। QoS 1 ਘੱਟੋ-ਘੱਟ ਇੱਕ ਵਾਰ ਪਹੁੰਚਾਉਣ ਦੀ ਗਰੰਟੀ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਨਕਲਾਂ ਆਮ ਹਨ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਦੁਹਰਾਉ-ਸੁਰੱਖਿਅਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਆਦਰਸ਼ ਰੂਪ ਵਿੱਚ ਅਜਿਹੇ ਪਛਾਣਕਰਤਾ ਜਾਂ ਸਮਾਂ-ਛਾਪ ਨਾਲ ਜਿਸ ਨੂੰ ਉਹ ਰੱਦ ਕਰ ਸਕੇ। ਆਖਰੀ ਇੱਛਾ ਉਪਕਰਣ ਡਿੱਗਣ ਵੇਲੇ ਤੁਹਾਨੂੰ ਸਥਿਤੀ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ, ਪਰ ਸਿਰਫ਼ ਤਦ ਜਦੋਂ ਕਨੈਕਸ਼ਨ ਅਸਲ ਵਿੱਚ ਫੇਲ ਹੋਵੇ, ਲਟਕੇ ਨਾ।

ਸਾਫ਼ ਸੈਸ਼ਨ ਦਾ ਵਿਵਹਾਰ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਬਾਹਰ ਹੁੰਦੇ ਸਮੇਂ ਬ੍ਰੋਕਰ ਤੁਹਾਡੀਆਂ ਗਾਹਕੀਆਂ ਰੱਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਸ ਵਿੱਚ ਗਲਤੀ ਕਰਨਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕੁਝ ਉਪਕਰਣ ਹਰ ਦੁਬਾਰਾ ਜੁੜਨ ਤੋਂ ਬਾਅਦ ਪਹਿਲਾ ਸੁਨੇਹਾ ਖੁੰਝਾ ਦਿੰਦੇ ਹਨ।

TLS ਬ੍ਰੋਕਰ ਤੱਕ ਦੇ ਹਿੱਸੇ ਦੀ ਰੱਖਿਆ ਕਰਦਾ ਹੈ। ਇਹ ਬ੍ਰੋਕਰ ਚਾਲਕ ਦੇ ਵਿਰੁੱਧ ਪੇਲੋਡ ਦਾ ਸਿਰੇ-ਤੋਂ-ਸਿਰੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ, ਜੋ ਤੁਹਾਡੇ ਵੱਲੋਂ ਇਸ ਰਾਹੀਂ ਪ੍ਰਕਾਸ਼ਿਤ ਹਰ ਚੀਜ਼ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

ਜੀਵਨ ਚੱਕਰ ਸੀਮਿਤ ਕਰੋ ਅਤੇ ਇਸ ਨੂੰ ਹਾਨੀਰਹਿਤ ਡੇਟਾ ਨਾਲ ਪਰਖੋ

ਸਖ਼ਤ ਦੁਬਾਰਾ-ਕੋਸ਼ਿਸ਼ ਲੂਪ ਦੀ ਥਾਂ ਬੈਕਆਫ਼ ਨਾਲ ਦੁਬਾਰਾ ਜੁੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾਓ, ਜੇ ਸੈਸ਼ਨ ਸਥਾਈ ਨਹੀਂ ਤਾਂ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਦੁਬਾਰਾ ਗਾਹਕੀ ਲਓ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਦਾ ਨਤੀਜਾ ਲੌਗ ਕਰੋ ਤਾਂ ਜੋ ਚੁੱਪ ਆਫਲਾਈਨ ਉਪਕਰਣ ਸਬੂਤ ਛੱਡੇ। ਦੁਬਾਰਾ ਜੁੜਨ ਦੇ ਰਾਹ ਨੂੰ ਅਜਿਹੇ ਨਮੂਨਾ ਪੇਲੋਡ ਨਾਲ ਪਰਖੋ ਜੋ ਕੁਝ ਨਹੀਂ ਕਰਦੇ, ਕਿਉਂਕਿ ਹੁਕਮ ਚੈਨਲ ਦੀ ਪਹਿਲੀ ਉਤਪਾਦਨ ਪਰਖ ਅਸਲੀ ਹੁਕਮ ਨਹੀਂ ਹੋਣੀ ਚਾਹੀਦੀ। ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਪੁਰਾਣਾ ਰੱਖਿਆ ਸੁਨੇਹਾ ਦੁਬਾਰਾ ਜੁੜਨ ਵੇਲੇ ਕੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਤੈਅ ਕਰੋ ਕਿ ਉਹ ਵਿਵਹਾਰ ਹਰ ਵਿਸ਼ੇ ਲਈ ਸਵੀਕਾਰਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ।

ਇਸ ਤਰ੍ਹਾਂ ਕਰਨ ਨਾਲ ਡਿਜ਼ਾਈਨ ਇੱਕ ਆਵਕ ਨੈੱਟਵਰਕ ਲੋੜ ਹਟਾਉਂਦਾ ਹੈ ਅਤੇ ਉਪਕਰਣ ਸਾਫ਼ਟਵੇਅਰ, ਬ੍ਰੋਕਰ ਨੀਤੀ ਅਤੇ ਸੁਨੇਹਾ-ਅਰਥਸ਼ਾਸਤਰ ਨੂੰ ਲੁਕੀਆਂ ਧਾਰਨਾਵਾਂ ਦੀ ਥਾਂ ਦਿਖਣ ਵਾਲੇ ਕੰਮ ਵਜੋਂ ਛੱਡਦਾ ਹੈ।