ਆਈਓਟੀ, ਧੁੰਦ ਅਤੇ ਬੱਦਲ: ਆਓ ਤਕਨਾਲੋਜੀ ਬਾਰੇ ਗੱਲ ਕਰੀਏ?

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

ਅੱਜ ਕੱਲ, ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਵਰਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। ਹਾਲਾਂਕਿ, ਵਧਦੀ ਪ੍ਰਸਿੱਧ ਫੋਗ ਕੰਪਿਊਟਿੰਗ (ਧੁੰਦ) ਪੈਰਾਡਾਈਮ ਆਈਓਟੀ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਨੂੰ ਸਕੇਲਿੰਗ ਅਤੇ ਅਨੁਕੂਲਿਤ ਕਰਕੇ ਕਲਾਉਡ ਹੱਲਾਂ ਦੀ ਪੂਰਤੀ ਕਰਨ ਦੇ ਯੋਗ ਹੈ।

ਕਲਾਉਡਜ਼ ਜ਼ਿਆਦਾਤਰ IoT ਬੇਨਤੀਆਂ ਨੂੰ ਬੰਦ ਕਰਨ ਦੇ ਸਮਰੱਥ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਸੇਵਾਵਾਂ ਦੀ ਨਿਗਰਾਨੀ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ, ਡਿਵਾਈਸਾਂ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤੇ ਗਏ ਡੇਟਾ ਦੀ ਕਿਸੇ ਵੀ ਮਾਤਰਾ ਦੀ ਤੇਜ਼ ਪ੍ਰਕਿਰਿਆ, ਅਤੇ ਨਾਲ ਹੀ ਉਹਨਾਂ ਦੀ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ। ਧੁੰਦ ਕੰਪਿਊਟਿੰਗ ਅਸਲ-ਸਮੇਂ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵਿੱਚ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ। ਉਹ ਬੇਨਤੀਆਂ ਦਾ ਤੇਜ਼ ਜਵਾਬ ਅਤੇ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਵਿੱਚ ਘੱਟੋ ਘੱਟ ਦੇਰੀ ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਭਾਵ, ਧੁੰਦ "ਬੱਦਲਾਂ" ਨੂੰ ਪੂਰਕ ਕਰਦੀ ਹੈ, ਇਸਦੀ ਸਮਰੱਥਾ ਨੂੰ ਵਧਾਉਂਦੀ ਹੈ.

ਹਾਲਾਂਕਿ, ਮੁੱਖ ਸਵਾਲ ਵੱਖਰਾ ਹੈ: IoT ਦੇ ਸੰਦਰਭ ਵਿੱਚ ਇਹ ਸਭ ਕਿਵੇਂ ਇੰਟਰੈਕਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ? ਇੱਕ ਯੂਨੀਫਾਈਡ IoT-Fog-Cloud ਸਿਸਟਮ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਕਿਹੜੇ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੋਣਗੇ?

HTTP ਦੇ ਜਾਪਦੇ ਦਬਦਬੇ ਦੇ ਬਾਵਜੂਦ, IoT, ਧੁੰਦ ਅਤੇ ਕਲਾਉਡ ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਹੋਰ ਹੱਲ ਵਰਤੇ ਜਾਂਦੇ ਹਨ। ਇਹ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ IoT ਨੂੰ ਸੁਰੱਖਿਆ, ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ, ਅਤੇ ਹੋਰ ਉਪਭੋਗਤਾ ਲੋੜਾਂ ਦੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸ ਸੈਂਸਰਾਂ ਦੀ ਕਾਰਜਕੁਸ਼ਲਤਾ ਨੂੰ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ।

ਪਰ ਸੰਦਰਭ ਆਰਕੀਟੈਕਚਰ ਅਤੇ ਸੰਚਾਰ ਮਿਆਰ ਦਾ ਕੋਈ ਇੱਕ ਵਿਚਾਰ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਇੱਕ ਨਵਾਂ ਪ੍ਰੋਟੋਕੋਲ ਬਣਾਉਣਾ ਜਾਂ ਖਾਸ IoT ਕਾਰਜਾਂ ਲਈ ਮੌਜੂਦਾ ਇੱਕ ਨੂੰ ਸੋਧਣਾ IT ਭਾਈਚਾਰੇ ਦਾ ਸਾਹਮਣਾ ਕਰਨ ਵਾਲੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਕਾਰਜਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਵਰਤਮਾਨ ਵਿੱਚ ਕਿਹੜੇ ਪ੍ਰੋਟੋਕੋਲ ਵਰਤੋਂ ਵਿੱਚ ਹਨ ਅਤੇ ਉਹ ਕੀ ਪੇਸ਼ਕਸ਼ ਕਰ ਸਕਦੇ ਹਨ? ਆਓ ਇਸ ਨੂੰ ਬਾਹਰ ਕੱਢੀਏ। ਪਰ ਪਹਿਲਾਂ, ਆਓ ਇੱਕ ਈਕੋਸਿਸਟਮ ਦੇ ਸਿਧਾਂਤਾਂ 'ਤੇ ਚਰਚਾ ਕਰੀਏ ਜਿਸ ਵਿੱਚ ਬੱਦਲ, ਧੁੰਦ ਅਤੇ ਚੀਜ਼ਾਂ ਦਾ ਇੰਟਰਨੈਟ ਆਪਸ ਵਿੱਚ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦਾ ਹੈ।

IoT ਫੋਗ-ਟੂ-ਕਲਾਊਡ (F2C) ਆਰਕੀਟੈਕਚਰ

ਤੁਸੀਂ ਸ਼ਾਇਦ ਦੇਖਿਆ ਹੋਵੇਗਾ ਕਿ IoT, ਬੱਦਲਾਂ ਅਤੇ ਧੁੰਦ ਦੇ ਤਰਕਸੰਗਤ ਅਤੇ ਤਾਲਮੇਲ ਵਾਲੇ ਪ੍ਰਬੰਧਨ ਨਾਲ ਜੁੜੇ ਲਾਭਾਂ ਅਤੇ ਫਾਇਦਿਆਂ ਦੀ ਪੜਚੋਲ ਕਰਨ ਲਈ ਕਿੰਨੀ ਮਿਹਨਤ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਜੇ ਨਹੀਂ, ਤਾਂ ਇੱਥੇ ਤਿੰਨ ਮਾਨਕੀਕਰਨ ਪਹਿਲਕਦਮੀਆਂ ਹਨ: ਓਪਨਫੌਗ ਕੰਸੋਰਟੀਅਮ, ਐਜ ਕੰਪਿਊਟਿੰਗ ਕੰਸੋਰਟੀਅਮ и mF2C H2020.

ਜੇ ਪਹਿਲਾਂ ਸਿਰਫ 2 ਪੱਧਰਾਂ 'ਤੇ ਵਿਚਾਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਕਲਾਉਡ ਅਤੇ ਐਂਡ ਡਿਵਾਈਸ, ਤਾਂ ਪ੍ਰਸਤਾਵਿਤ ਆਰਕੀਟੈਕਚਰ ਇੱਕ ਨਵਾਂ ਪੱਧਰ ਪੇਸ਼ ਕਰਦਾ ਹੈ - fog computing. ਉਸੇ ਸਮੇਂ, ਧੁੰਦ ਦੇ ਪੱਧਰ ਨੂੰ ਸਰੋਤਾਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜਾਂ ਇਹਨਾਂ ਉਪ-ਪੱਧਰਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਵਾਲੀਆਂ ਨੀਤੀਆਂ ਦੇ ਸਮੂਹ ਦੇ ਅਧਾਰ ਤੇ, ਕਈ ਉਪ-ਪੱਧਰਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਇਹ ਐਬਸਟਰੈਕਸ਼ਨ ਕਿਹੋ ਜਿਹਾ ਦਿਖਾਈ ਦੇ ਸਕਦਾ ਹੈ? ਇੱਥੇ ਇੱਕ ਆਮ IoT-Fog-Cloud ਈਕੋਸਿਸਟਮ ਹੈ। IoT ਡਿਵਾਈਸਾਂ ਉਹਨਾਂ ਕੰਮਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਤੇਜ਼ ਸਰਵਰਾਂ ਅਤੇ ਕੰਪਿਊਟਿੰਗ ਡਿਵਾਈਸਾਂ ਨੂੰ ਡਾਟਾ ਭੇਜਦੀਆਂ ਹਨ ਜਿਹਨਾਂ ਲਈ ਘੱਟ ਲੇਟੈਂਸੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਸੇ ਸਿਸਟਮ ਵਿੱਚ, ਕਲਾਉਡ ਉਹਨਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਜਿੰਮੇਵਾਰ ਹੁੰਦੇ ਹਨ ਜਿਹਨਾਂ ਲਈ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਜਾਂ ਸਟੋਰੇਜ ਸਪੇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਸਮਾਰਟਫ਼ੋਨ, ਸਮਾਰਟ ਘੜੀਆਂ ਅਤੇ ਹੋਰ ਗੈਜੇਟਸ ਵੀ IoT ਦਾ ਹਿੱਸਾ ਹੋ ਸਕਦੇ ਹਨ। ਪਰ ਅਜਿਹੇ ਯੰਤਰ ਮੁੱਖ ਡਿਵੈਲਪਰਾਂ ਤੋਂ ਮਲਕੀਅਤ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਤਿਆਰ ਕੀਤਾ ਗਿਆ IoT ਡੇਟਾ REST HTTP ਪ੍ਰੋਟੋਕੋਲ ਦੁਆਰਾ ਧੁੰਦ ਦੀ ਪਰਤ ਨੂੰ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ RESTful ਸੇਵਾਵਾਂ ਬਣਾਉਣ ਵੇਲੇ ਲਚਕਤਾ ਅਤੇ ਅੰਤਰ-ਕਾਰਜਸ਼ੀਲਤਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਸਥਾਨਕ ਕੰਪਿਊਟਰਾਂ, ਸਰਵਰਾਂ, ਜਾਂ ਸਰਵਰ ਕਲੱਸਟਰ 'ਤੇ ਚੱਲ ਰਹੇ ਮੌਜੂਦਾ ਕੰਪਿਊਟਿੰਗ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਦੇ ਮੱਦੇਨਜ਼ਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਸਥਾਨਕ ਸਰੋਤ, ਜਿਨ੍ਹਾਂ ਨੂੰ "ਫੌਗ ਨੋਡ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਨੂੰ ਫਿਲਟਰ ਕਰਦੇ ਹਨ ਅਤੇ ਇਸਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹਨ ਜਾਂ ਅੱਗੇ ਦੀ ਗਣਨਾ ਲਈ ਕਲਾਉਡ ਨੂੰ ਭੇਜਦੇ ਹਨ।

ਕਲਾਉਡ ਵੱਖ-ਵੱਖ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ AMQP ਅਤੇ REST HTTP ਸਭ ਤੋਂ ਆਮ ਹਨ। ਕਿਉਂਕਿ HTTP ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੰਟਰਨੈਟ ਲਈ ਤਿੱਖਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਸਵਾਲ ਪੈਦਾ ਹੋ ਸਕਦਾ ਹੈ: "ਕੀ ਇਸਦੀ ਵਰਤੋਂ IoT ਅਤੇ ਧੁੰਦ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਨਹੀਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ?". ਹਾਲਾਂਕਿ, ਇਸ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਮੁੱਦੇ ਹਨ। ਇਸ ਬਾਰੇ ਹੋਰ ਬਾਅਦ ਵਿੱਚ.

ਆਮ ਤੌਰ 'ਤੇ, ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਸਿਸਟਮ ਲਈ ਢੁਕਵੇਂ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ ਦੇ 2 ਮਾਡਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਬੇਨਤੀ-ਜਵਾਬ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ-ਸਬਸਕ੍ਰਾਈਬ ਹਨ। ਪਹਿਲਾ ਮਾਡਲ ਵਧੇਰੇ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਸਰਵਰ-ਕਲਾਇੰਟ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ। ਕਲਾਇੰਟ ਸਰਵਰ ਤੋਂ ਜਾਣਕਾਰੀ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਅਤੇ ਬਾਅਦ ਵਾਲੇ ਨੂੰ ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ, ਇਸਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਜਵਾਬ ਸੁਨੇਹਾ ਵਾਪਸ ਕਰਦਾ ਹੈ। REST HTTP ਅਤੇ CoAP ਪ੍ਰੋਟੋਕੋਲ ਇਸ ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੇ ਹਨ।

ਦੂਜਾ ਮਾਡਲ ਡੇਟਾ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਸਰੋਤਾਂ ਅਤੇ ਇਸ ਡੇਟਾ ਦੇ ਪ੍ਰਾਪਤਕਰਤਾਵਾਂ ਵਿਚਕਾਰ ਅਸਿੰਕ੍ਰੋਨਸ, ਵੰਡਿਆ, ਢਿੱਲਾ ਜੋੜ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਤੋਂ ਪੈਦਾ ਹੋਇਆ।

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

ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਇਹ ਆਰਕੀਟੈਕਚਰ ਘਟਨਾਵਾਂ 'ਤੇ ਅਧਾਰਤ ਹੈ। ਅਤੇ ਇਹ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਮਾਡਲ IoT, ਕਲਾਉਡ, ਧੁੰਦ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਦਿਲਚਸਪ ਹੈ ਕਿਉਂਕਿ ਇਸਦੀ ਸਕੇਲੇਬਿਲਟੀ ਪ੍ਰਦਾਨ ਕਰਨ ਅਤੇ ਵੱਖ-ਵੱਖ ਡਿਵਾਈਸਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਕਨੈਕਸ਼ਨ ਨੂੰ ਸਰਲ ਬਣਾਉਣ, ਕਈ-ਤੋਂ-ਬਹੁਤ ਗਤੀਸ਼ੀਲ ਸੰਚਾਰ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ ਸੰਚਾਰ ਦਾ ਸਮਰਥਨ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਹੈ। ਕੁਝ ਸਭ ਤੋਂ ਮਸ਼ਹੂਰ ਮਾਨਕੀਕ੍ਰਿਤ ਪਬਲਿਸ਼-ਸਬਸਕ੍ਰਾਈਬ ਮੈਸੇਜਿੰਗ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ MQTT, AMQP, ਅਤੇ DDS ਸ਼ਾਮਲ ਹਨ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਪਬਲਿਸ਼-ਸਬਸਕ੍ਰਾਈਬ ਮਾਡਲ ਦੇ ਬਹੁਤ ਸਾਰੇ ਫਾਇਦੇ ਹਨ:

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

ਹਾਲਾਂਕਿ, ਬੇਨਤੀ-ਜਵਾਬ ਮਾਡਲ ਦੀਆਂ ਆਪਣੀਆਂ ਸ਼ਕਤੀਆਂ ਵੀ ਹਨ। ਉਹਨਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਜਿੱਥੇ ਸਰਵਰ ਸਾਈਡ ਦੀ ਮਲਟੀਪਲ ਕਲਾਇੰਟਸ ਤੋਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਸਮਰੱਥਾ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ, ਇਹ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਸਾਬਤ ਹੋਏ ਭਰੋਸੇਮੰਦ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਮਝਦਾਰ ਹੈ।

ਅਜਿਹੇ ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਹਨ ਜੋ ਦੋਵਾਂ ਮਾਡਲਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, XMPP ਅਤੇ HTTP 2.0 "ਸਰਵਰ ਪੁਸ਼" ਵਿਕਲਪ ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ। IETF ਨੇ CoAP ਵੀ ਜਾਰੀ ਕੀਤਾ ਹੈ। ਮੈਸੇਜਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਕਈ ਹੋਰ ਹੱਲ ਬਣਾਏ ਗਏ ਹਨ, ਜਿਵੇਂ ਕਿ WebSockets ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ QUIC (Quick UDP ਇੰਟਰਨੈਟ ਕਨੈਕਸ਼ਨ) ਉੱਤੇ HTTP ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ।

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

ਦੁਨੀਆ ਵਿੱਚ ਸਭ ਤੋਂ ਪਿਆਰਾ ਕੌਣ ਹੈ: ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਤੁਲਨਾ ਕਰਨਾ

ਆਓ ਹੁਣ ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਸ਼ਕਤੀਆਂ ਅਤੇ ਕਮਜ਼ੋਰੀਆਂ ਬਾਰੇ ਗੱਲ ਕਰੀਏ. ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਅਸੀਂ ਤੁਰੰਤ ਇੱਕ ਰਿਜ਼ਰਵੇਸ਼ਨ ਬਣਾਵਾਂਗੇ ਕਿ ਕੋਈ ਵੀ ਸਪੱਸ਼ਟ ਨੇਤਾ ਨਹੀਂ ਹੈ. ਹਰੇਕ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਕੁਝ ਫਾਇਦੇ/ਨੁਕਸਾਨ ਹੁੰਦੇ ਹਨ।

ਜਵਾਬ ਟਾਈਮ

ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ ਦੀਆਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ, ਖਾਸ ਤੌਰ 'ਤੇ ਚੀਜ਼ਾਂ ਦੇ ਇੰਟਰਨੈਟ ਦੇ ਸਬੰਧ ਵਿੱਚ, ਜਵਾਬ ਸਮਾਂ ਹੈ। ਪਰ ਮੌਜੂਦਾ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ, ਕੋਈ ਸਪੱਸ਼ਟ ਵਿਜੇਤਾ ਨਹੀਂ ਹੈ ਜੋ ਵੱਖ-ਵੱਖ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵੇਲੇ ਘੱਟੋ-ਘੱਟ ਦੇਰੀ ਦਾ ਪੱਧਰ ਦਰਸਾਉਂਦਾ ਹੈ। ਪਰ ਪ੍ਰੋਟੋਕੋਲ ਸਮਰੱਥਾਵਾਂ ਦੇ ਅਧਿਐਨ ਅਤੇ ਤੁਲਨਾਵਾਂ ਦਾ ਇੱਕ ਪੂਰਾ ਸਮੂਹ ਹੈ।

ਮਿਸਾਲ ਲਈ, ਨਤੀਜੇ IoT ਦੇ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ HTTP ਅਤੇ MQTT ਦੀ ਪ੍ਰਭਾਵਸ਼ੀਲਤਾ ਦੀ ਤੁਲਨਾ ਨੇ ਦਿਖਾਇਆ ਕਿ MQTT ਲਈ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਸਮਾਂ HTTP ਨਾਲੋਂ ਘੱਟ ਹੈ। ਅਤੇ ਕਦੋਂ ਪੜ੍ਹਾਈ MQTT ਅਤੇ CoAP ਦਾ ਰਾਉਂਡ-ਟ੍ਰਿਪ ਟਾਈਮ (RTT), ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ CoAP ਦਾ ਔਸਤ RTT MQTT ਤੋਂ 20% ਘੱਟ ਹੈ।

ਹੋਰ ਪ੍ਰਯੋਗ MQTT ਅਤੇ CoAP ਪ੍ਰੋਟੋਕੋਲ ਲਈ RTT ਦੇ ਨਾਲ ਦੋ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਕੀਤਾ ਗਿਆ ਸੀ: ਇੱਕ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਅਤੇ ਇੱਕ IoT ਨੈੱਟਵਰਕ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਔਸਤ RTT IoT ਨੈਟਵਰਕ ਵਿੱਚ 2-3 ਗੁਣਾ ਵੱਧ ਹੈ. QoS0 ਦੇ ਨਾਲ MQTT ਨੇ CoAP ਦੇ ਮੁਕਾਬਲੇ ਇੱਕ ਘੱਟ ਨਤੀਜਾ ਦਿਖਾਇਆ, ਅਤੇ QoS1 ਦੇ ਨਾਲ MQTT ਨੇ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਟ੍ਰਾਂਸਪੋਰਟ ਲੇਅਰਾਂ 'ਤੇ ACKs ਲਈ ਇੱਕ ਉੱਚ RTT ਧੰਨਵਾਦ ਦਿਖਾਇਆ। ਵੱਖ-ਵੱਖ QoS ਪੱਧਰਾਂ ਲਈ, ਭੀੜ-ਭੜੱਕੇ ਤੋਂ ਬਿਨਾਂ ਨੈੱਟਵਰਕ ਦੇਰੀ MQTT ਲਈ ਮਿਲੀਸਕਿੰਟ, ਅਤੇ CoAP ਲਈ ਸੈਂਕੜੇ ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ ਸਨ। ਹਾਲਾਂਕਿ, ਇਹ ਯਾਦ ਰੱਖਣ ਯੋਗ ਹੈ ਕਿ ਘੱਟ ਭਰੋਸੇਮੰਦ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, TCP ਉੱਤੇ ਚੱਲ ਰਹੇ MQTT ਇੱਕ ਬਿਲਕੁਲ ਵੱਖਰਾ ਨਤੀਜਾ ਦਿਖਾਏਗਾ।

ਤੁਲਨਾ ਪੇਲੋਡ ਨੂੰ ਵਧਾ ਕੇ AMQP ਅਤੇ MQTT ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਜਵਾਬ ਸਮੇਂ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇੱਕ ਛੋਟੇ ਲੋਡ ਦੇ ਨਾਲ, ਦੇਰੀ ਦਾ ਪੱਧਰ ਲਗਭਗ ਇੱਕੋ ਜਿਹਾ ਹੈ। ਪਰ ਜਦੋਂ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ MQTT ਘੱਟ ਜਵਾਬ ਸਮਾਂ ਦਿਖਾਉਂਦਾ ਹੈ। ਇੱਕ ਹੋਰ ਵਿੱਚ ਖੋਜ ਗੈਸ ਸੈਂਸਰ, ਮੌਸਮ ਸੈਂਸਰ, ਲੋਕੇਸ਼ਨ (ਜੀਪੀਐਸ) ਅਤੇ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸ (ਜੀਪੀਆਰਐਸ) ਨਾਲ ਲੈਸ ਵਾਹਨਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਤੈਨਾਤ ਡਿਵਾਈਸਾਂ ਦੇ ਨਾਲ ਮਸ਼ੀਨ-ਟੂ-ਮਸ਼ੀਨ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਸੀਓਏਪੀ ਦੀ ਤੁਲਨਾ HTTP ਨਾਲ ਕੀਤੀ ਗਈ ਸੀ। ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ 'ਤੇ ਇੱਕ CoAP ਸੁਨੇਹਾ ਭੇਜਣ ਵਿੱਚ ਲੱਗਣ ਵਾਲਾ ਸਮਾਂ HTTP ਸੁਨੇਹਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ ਲੱਗੇ ਸਮੇਂ ਨਾਲੋਂ ਲਗਭਗ ਤਿੰਨ ਗੁਣਾ ਘੱਟ ਸੀ।

ਅਧਿਐਨ ਕੀਤੇ ਗਏ ਹਨ ਜੋ ਦੋ ਨਹੀਂ, ਪਰ ਤਿੰਨ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹਨ. ਉਦਾਹਰਣ ਲਈ, ਤੁਲਨਾ ਇੱਕ ਨੈਟਵਰਕ ਇਮੂਲੇਟਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਮੈਡੀਕਲ ਐਪਲੀਕੇਸ਼ਨ ਦ੍ਰਿਸ਼ ਵਿੱਚ IoT ਪ੍ਰੋਟੋਕੋਲ MQTT, DDS ਅਤੇ CoAP ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ। ਡੀਡੀਐਸ ਨੇ ਵੱਖ-ਵੱਖ ਮਾੜੀਆਂ ਨੈੱਟਵਰਕ ਹਾਲਤਾਂ ਵਿੱਚ ਟੈਲੀਮੈਟਰੀ ਲੇਟੈਂਸੀ ਦੀ ਜਾਂਚ ਦੇ ਮਾਮਲੇ ਵਿੱਚ MQTT ਨੂੰ ਪਛਾੜ ਦਿੱਤਾ ਹੈ। UDP-ਅਧਾਰਿਤ CoAP ਨੇ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕੀਤਾ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੇਜ਼ ਜਵਾਬ ਦੀ ਲੋੜ ਸੀ, ਹਾਲਾਂਕਿ, UDP-ਅਧਾਰਿਤ ਹੋਣ ਦੇ ਕਾਰਨ, ਮਹੱਤਵਪੂਰਨ ਅਨਿਸ਼ਚਿਤ ਪੈਕੇਟ ਨੁਕਸਾਨ ਸੀ।

ਬੈਂਡਵਿਡਥ

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

'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ MQTT, DDS (ਟ੍ਰਾਂਸਪੋਰਟ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ TCP ਦੇ ਨਾਲ), ਅਤੇ CoAP ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਥ੍ਰੁਪੁੱਟ ਨੇ ਪਾਇਆ ਕਿ CoAP ਤੁਲਨਾਤਮਕ ਤੌਰ 'ਤੇ ਘੱਟ ਬੈਂਡਵਿਡਥ ਦੀ ਖਪਤ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ MQTT ਅਤੇ DDS ਦੇ ਉਲਟ, ਵਧੇ ਹੋਏ ਨੈੱਟਵਰਕ ਪੈਕੇਟ ਨੁਕਸਾਨ ਜਾਂ ਵਧੇ ਹੋਏ ਨੈੱਟਵਰਕ ਲੇਟੈਂਸੀ ਨਾਲ ਨਹੀਂ ਵਧਿਆ, ਜਿੱਥੇ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਹੈ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਬੈਂਡਵਿਡਥ ਦੀ ਵਰਤੋਂ ਵਿੱਚ ਵਾਧਾ ਹੋਇਆ ਸੀ। ਇੱਕ ਹੋਰ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ ਡੇਟਾ ਸੰਚਾਰਿਤ ਕਰਨ ਵਾਲੀਆਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਡਿਵਾਈਸਾਂ ਸ਼ਾਮਲ ਹੁੰਦੀਆਂ ਹਨ, ਜੋ ਕਿ IoT ਵਾਤਾਵਰਨ ਵਿੱਚ ਇੱਕ ਆਮ ਮਾਮਲਾ ਹੈ। ਨਤੀਜਿਆਂ ਨੇ ਦਿਖਾਇਆ ਕਿ ਉੱਚ ਲੋਡਿੰਗ ਲਈ CoAP ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ।

ਹਲਕੇ ਲੋਡ ਦੇ ਅਧੀਨ, CoAP ਨੇ ਸਭ ਤੋਂ ਘੱਟ ਬੈਂਡਵਿਡਥ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਇਸਦੇ ਬਾਅਦ MQTT ਅਤੇ REST HTTP. ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਪੇਲੋਡ ਦਾ ਆਕਾਰ ਵਧਿਆ, REST HTTP ਦੇ ਵਧੀਆ ਨਤੀਜੇ ਸਨ।

ਪਾਵਰ ਖਪਤ

ਊਰਜਾ ਦੀ ਖਪਤ ਦਾ ਮੁੱਦਾ ਹਮੇਸ਼ਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਖਾਸ ਤੌਰ 'ਤੇ IoT ਸਿਸਟਮ ਵਿੱਚ. ਜੇ ਤੁਲਨਾ ਕਰੋ MQTT ਅਤੇ HTTP ਦੀ ਬਿਜਲੀ ਦੀ ਖਪਤ, HTTP ਬਹੁਤ ਜ਼ਿਆਦਾ "ਖਾਦਾ ਹੈ"। ਅਤੇ CoAP ਹੋਰ ਹੈ ਊਰਜਾ ਕੁਸ਼ਲ MQTT ਦੇ ਮੁਕਾਬਲੇ, ਪਾਵਰ ਪ੍ਰਬੰਧਨ ਲਈ ਆਗਿਆ ਦਿੰਦਾ ਹੈ. ਇਸਦੇ ਨਾਲ ਹੀ, ਸਧਾਰਨ ਸਥਿਤੀਆਂ ਵਿੱਚ, MQTT ਇੰਟਰਨੈਟ ਆਫ ਥਿੰਗਸ ਨੈਟਵਰਕ ਵਿੱਚ ਜਾਣਕਾਰੀ ਦੇ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਕੋਈ ਪਾਵਰ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਹਨ।

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

ਸੁਰੱਖਿਆ ਨੂੰ

ਇੰਟਰਨੈੱਟ ਆਫ਼ ਥਿੰਗਜ਼ ਅਤੇ ਫੋਗ/ਕਲਾਊਡ ਕੰਪਿਊਟਿੰਗ ਦੇ ਅਧਿਐਨ ਵਿੱਚ ਸੁਰੱਖਿਆ ਇੱਕ ਹੋਰ ਪ੍ਰਮੁੱਖ ਮੁੱਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਵਿਧੀ ਆਮ ਤੌਰ 'ਤੇ HTTP, MQTT, AMQP, ਅਤੇ XMPP, ਜਾਂ CoAP ਵਿੱਚ DTLS ਵਿੱਚ TLS 'ਤੇ ਅਧਾਰਤ ਹੈ, ਅਤੇ ਦੋਵਾਂ DDS ਵਿਕਲਪਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ।

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

'ਤੇ ਟੈਸਟ ਹਮਲੇ TLS ਅਤੇ DTLS ਦੇ ਕਈ ਵੱਖ-ਵੱਖ ਲਾਗੂਕਰਨਾਂ 'ਤੇ, ਇਹ ਪਤਾ ਲੱਗਾ ਕਿ TLS ਨੇ ਵਧੀਆ ਕੰਮ ਕੀਤਾ ਹੈ। DTLS 'ਤੇ ਹਮਲੇ ਇਸਦੀ ਗਲਤੀ ਸਹਿਣਸ਼ੀਲਤਾ ਦੇ ਕਾਰਨ ਵਧੇਰੇ ਸਫਲ ਰਹੇ ਹਨ।

ਹਾਲਾਂਕਿ, ਇਹਨਾਂ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਡੀ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ ਉਹ ਅਸਲ ਵਿੱਚ IoT ਵਿੱਚ ਵਰਤੋਂ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ ਅਤੇ ਧੁੰਦ ਜਾਂ ਬੱਦਲ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ ਨਹੀਂ ਸਨ। ਹੈਂਡਸ਼ੇਕਿੰਗ ਦੁਆਰਾ, ਉਹ ਹਰੇਕ ਕਨੈਕਸ਼ਨ ਸਥਾਪਨਾ ਦੇ ਨਾਲ ਵਾਧੂ ਟ੍ਰੈਫਿਕ ਜੋੜਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਦਾ ਨਿਕਾਸ ਹੁੰਦਾ ਹੈ। ਔਸਤਨ, ਬਿਨਾਂ ਸੁਰੱਖਿਆ ਪਰਤ ਦੇ ਸੰਚਾਰ ਦੇ ਮੁਕਾਬਲੇ TLS ਲਈ 6,5% ਅਤੇ ਓਵਰਹੈੱਡ ਵਿੱਚ DTLS ਲਈ 11% ਦਾ ਵਾਧਾ ਹੈ। ਸਰੋਤ-ਅਮੀਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਸਥਿਤ ਹੁੰਦੇ ਹਨ ਬੱਦਲਵਾਈ ਪੱਧਰ, ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋਵੇਗੀ, ਪਰ IoT ਅਤੇ ਧੁੰਦ ਦੇ ਪੱਧਰ ਦੇ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦੇ ਕਾਰਨ, ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਸੀਮਾ ਬਣ ਜਾਂਦੀ ਹੈ।

ਕੀ ਚੁਣਨਾ ਹੈ? ਕੋਈ ਇਕੱਲਾ ਜਵਾਬ ਨਹੀਂ ਹੈ। MQTT ਅਤੇ HTTP ਸਭ ਤੋਂ ਵਧੀਆ ਪ੍ਰੋਟੋਕੋਲ ਜਾਪਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਦੂਜੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨਾਲੋਂ ਮੁਕਾਬਲਤਨ ਵਧੇਰੇ ਪਰਿਪੱਕ ਅਤੇ ਵਧੇਰੇ ਸਥਿਰ IoT ਹੱਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

ਇੱਕ ਸਿੰਗਲ ਸੰਚਾਰ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਅਧਾਰਤ ਹੱਲ

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

ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਟੋਕੋਲ ਹੱਲ ਵਜੋਂ REST HTTP

IoT-ਟੂ-ਫੌਗ ਖੇਤਰ ਵਿੱਚ REST HTTP ਬੇਨਤੀ/ਜਵਾਬ ਇੰਟਰੈਕਸ਼ਨ ਦੀ ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਣ ਹੈ: ਸਮਾਰਟ ਫਾਰਮ. ਜਾਨਵਰ ਪਹਿਨਣਯੋਗ ਸੈਂਸਰ (IoT ਕਲਾਇੰਟ, C) ਨਾਲ ਲੈਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸਮਾਰਟ ਫਾਰਮਿੰਗ ਸਿਸਟਮ (ਫੌਗ ਸਰਵਰ, ਐਸ) ਦੁਆਰਾ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

POST ਵਿਧੀ ਸਿਰਲੇਖ (/farm/animals), ਅਤੇ ਨਾਲ ਹੀ HTTP ਸੰਸਕਰਣ ਅਤੇ ਸਮੱਗਰੀ ਦੀ ਕਿਸਮ ਨੂੰ ਸੰਸ਼ੋਧਿਤ ਕਰਨ ਲਈ ਸਰੋਤ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ JSON ਵਸਤੂ ਹੈ ਜੋ ਜਾਨਵਰਾਂ ਦੇ ਫਾਰਮ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਿਸਦਾ ਸਿਸਟਮ ਨੂੰ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਡੁਲਸੀਨੀਆ/ਗਾਂ)। ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਬੇਨਤੀ HTTPS 201 (ਸਰੋਤ ਬਣਾਏ ਗਏ) ਸਥਿਤੀ ਕੋਡ ਨਾਲ ਸਫਲ ਸੀ। GET ਵਿਧੀ ਨੂੰ ਸਿਰਫ਼ URI ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, /farm/animals/1), ਜੋ ਸਰਵਰ ਤੋਂ ਉਸ ID ਨਾਲ ਜਾਨਵਰ ਦੀ JSON ਪ੍ਰਤੀਨਿਧਤਾ ਵਾਪਸ ਕਰਦਾ ਹੈ।

PUT ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਉਦੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਜਦੋਂ ਕੁਝ ਖਾਸ ਸਰੋਤ ਰਿਕਾਰਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਰੋਤ ਬਦਲੇ ਜਾਣ ਵਾਲੇ ਪੈਰਾਮੀਟਰ ਅਤੇ ਮੌਜੂਦਾ ਮੁੱਲ ਲਈ URI ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਗਊ ਵਰਤਮਾਨ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ, /farm/animals/1? state=walking)। ਅੰਤ ਵਿੱਚ, DELETE ਵਿਧੀ ਨੂੰ GET ਵਿਧੀ ਵਾਂਗ ਹੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਕਾਰਵਾਈ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਸਰੋਤ ਨੂੰ ਸਿਰਫ਼ ਮਿਟਾਉਂਦਾ ਹੈ।

ਇੱਕ ਸਿੰਗਲ ਪ੍ਰੋਟੋਕੋਲ ਹੱਲ ਵਜੋਂ MQTT

ਚਲੋ ਉਹੀ ਸਮਾਰਟ ਫਾਰਮ ਲੈਂਦੇ ਹਾਂ, ਪਰ REST HTTP ਦੀ ਬਜਾਏ ਅਸੀਂ MQTT ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। Mosquitto ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਨਾਲ ਸਥਾਨਕ ਸਰਵਰ ਇੱਕ ਦਲਾਲ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ, ਇੱਕ ਸਧਾਰਨ ਕੰਪਿਊਟਰ (ਜਿਸਨੂੰ ਫਾਰਮ ਸਰਵਰ ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ) Raspberry Pi ਇੱਕ MQTT ਕਲਾਇੰਟ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ Paho MQTT ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਸਥਾਪਨਾ ਦੁਆਰਾ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਮੌਸਕੀਟੋ ਬ੍ਰੋਕਰ ਦੇ ਨਾਲ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਨੁਕੂਲ ਹੈ।

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

ਪ੍ਰਸਤਾਵਿਤ ਸਮਾਰਟ ਫਾਰਮ ਦ੍ਰਿਸ਼ ਵਿੱਚ, ਇੱਕ Raspberry Pi ਇੱਕ ਐਕਸਲੇਰੋਮੀਟਰ, GPS, ਅਤੇ ਤਾਪਮਾਨ ਸੈਂਸਰਾਂ ਨਾਲ ਜੁੜਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਸੈਂਸਰਾਂ ਤੋਂ ਡੇਟਾ ਨੂੰ ਇੱਕ ਧੁੰਦ ਨੋਡ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਸ਼ਾਇਦ ਜਾਣਦੇ ਹੋ, MQTT ਵਿਸ਼ਿਆਂ ਨੂੰ ਇੱਕ ਲੜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਮੰਨਦਾ ਹੈ। ਇੱਕ MQTT ਪ੍ਰਕਾਸ਼ਕ ਵਿਸ਼ਿਆਂ ਦੇ ਇੱਕ ਖਾਸ ਸਮੂਹ ਲਈ ਸੰਦੇਸ਼ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਤਿੰਨ ਹਨ. ਸੈਂਸਰ ਲਈ ਜੋ ਜਾਨਵਰਾਂ ਦੇ ਸ਼ੈੱਡ ਵਿੱਚ ਤਾਪਮਾਨ ਨੂੰ ਮਾਪਦਾ ਹੈ, ਗਾਹਕ ਇੱਕ ਥੀਮ (ਜਾਨਵਰ ਫਾਰਮ/ਸ਼ੈੱਡ/ਤਾਪਮਾਨ) ਚੁਣਦਾ ਹੈ। ਐਕਸੀਲੇਰੋਮੀਟਰ ਦੁਆਰਾ GPS ਸਥਾਨ ਅਤੇ ਜਾਨਵਰਾਂ ਦੀ ਗਤੀ ਨੂੰ ਮਾਪਣ ਵਾਲੇ ਸੈਂਸਰਾਂ ਲਈ, ਕਲਾਇੰਟ (ਐਨੀਮਲਫਾਰਮ/ਜਾਨਵਰ/ਜੀਪੀਐਸ) ਅਤੇ (ਐਨੀਮਲਫਾਰਮ/ਜਾਨਵਰ/ਮੂਵਮੈਂਟ) ਲਈ ਅੱਪਡੇਟ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੇਗਾ।

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

ਸਥਾਨਕ ਸਰਵਰ ਤੋਂ ਇਲਾਵਾ ਜੋ ਧੁੰਦ ਵਿੱਚ ਇੱਕ MQTT ਬ੍ਰੋਕਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਜਿਸਨੂੰ ਰਾਸਬੇਰੀ Pi, MQTT ਗਾਹਕ ਵਜੋਂ ਕੰਮ ਕਰਦੇ ਹੋਏ, ਸੈਂਸਰਾਂ ਤੋਂ ਡੇਟਾ ਭੇਜਦੇ ਹਨ, ਕਲਾਉਡ ਪੱਧਰ 'ਤੇ ਇੱਕ ਹੋਰ MQTT ਬ੍ਰੋਕਰ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਥਾਨਕ ਬ੍ਰੋਕਰ ਨੂੰ ਭੇਜੀ ਗਈ ਜਾਣਕਾਰੀ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਇੱਕ ਸਥਾਨਕ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ/ਜਾਂ ਕਲਾਉਡ ਨੂੰ ਭੇਜੀ ਜਾ ਸਕਦੀ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਕਲਾਉਡ MQTT ਬ੍ਰੋਕਰ ਦੀ ਵਰਤੋਂ ਸਾਰੇ ਡੇਟਾ ਨੂੰ ਕਲਾਉਡ MQTT ਬ੍ਰੋਕਰ ਨਾਲ ਲਿੰਕ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਆਰਕੀਟੈਕਚਰ ਦੇ ਨਾਲ, ਇੱਕ ਮੋਬਾਈਲ ਐਪਲੀਕੇਸ਼ਨ ਉਪਭੋਗਤਾ ਦੋਵਾਂ ਦਲਾਲਾਂ ਦੀ ਗਾਹਕੀ ਲੈ ਸਕਦਾ ਹੈ।

ਕਿਸੇ ਇੱਕ ਦਲਾਲ (ਉਦਾਹਰਣ ਵਜੋਂ, ਕਲਾਉਡ) ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਅਸਫਲ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ, ਅੰਤਮ ਉਪਭੋਗਤਾ ਕਿਸੇ ਹੋਰ (ਧੁੰਦ ਵਾਲੇ) ਤੋਂ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰੇਗਾ। ਇਹ ਸੰਯੁਕਤ ਧੁੰਦ ਅਤੇ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ, ਮੋਬਾਈਲ ਐਪ ਨੂੰ ਪਹਿਲਾਂ ਧੁੰਦ ਵਾਲੇ MQTT ਬ੍ਰੋਕਰ ਨਾਲ ਜੁੜਨ ਲਈ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਅਜਿਹਾ ਨਾ ਕਰਨ 'ਤੇ, ਕਲਾਉਡ MQTT ਬ੍ਰੋਕਰ ਨਾਲ ਜੁੜਨ ਲਈ। ਇਹ ਹੱਲ IoT-F2C ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਵਿੱਚੋਂ ਇੱਕ ਹੈ।

ਮਲਟੀਪ੍ਰੋਟੋਕੋਲ ਹੱਲ

ਸਿੰਗਲ ਪ੍ਰੋਟੋਕੋਲ ਹੱਲ ਉਹਨਾਂ ਦੇ ਆਸਾਨ ਲਾਗੂ ਕਰਨ ਦੇ ਕਾਰਨ ਪ੍ਰਸਿੱਧ ਹਨ। ਪਰ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ IoT-F2C ਪ੍ਰਣਾਲੀਆਂ ਵਿੱਚ ਇਹ ਵੱਖੋ-ਵੱਖਰੇ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਜੋੜਨਾ ਸਮਝਦਾ ਹੈ। ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਟੋਕੋਲ ਵੱਖ-ਵੱਖ ਪੱਧਰਾਂ 'ਤੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਤਿੰਨ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਨੂੰ ਲਓ: IoT, ਧੁੰਦ, ਅਤੇ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ ਲੇਅਰਾਂ। IoT ਪੱਧਰ 'ਤੇ ਡਿਵਾਈਸਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਸੀਮਤ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਸੰਖੇਪ ਜਾਣਕਾਰੀ ਲਈ, ਆਓ IoT ਲੇਅਰਾਂ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਤਿਬੰਧਿਤ, ਕਲਾਉਡ-ਅਧਾਰਿਤ ਘੱਟ ਤੋਂ ਘੱਟ ਪ੍ਰਤਿਬੰਧਿਤ, ਅਤੇ ਧੁੰਦ ਕੰਪਿਊਟਿੰਗ ਨੂੰ "ਕਿਤੇ ਦੇ ਵਿਚਕਾਰ" ਵਜੋਂ ਵੇਖੀਏ। ਫਿਰ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ IoT ਅਤੇ ਧੁੰਦ ਦੇ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ, ਮੌਜੂਦਾ ਪ੍ਰੋਟੋਕੋਲ ਹੱਲਾਂ ਵਿੱਚ MQTT, CoAP ਅਤੇ XMPP ਸ਼ਾਮਲ ਹਨ. ਧੁੰਦ ਅਤੇ ਬੱਦਲ ਦੇ ਵਿਚਕਾਰ, ਦੂਜੇ ਪਾਸੇ, AMQP REST HTTP ਦੇ ਨਾਲ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਮੁੱਖ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਜੋ ਕਿ ਇਸਦੀ ਲਚਕਤਾ ਦੇ ਕਾਰਨ ਆਈਓਟੀ ਅਤੇ ਧੁੰਦ ਦੀਆਂ ਪਰਤਾਂ ਦੇ ਵਿਚਕਾਰ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

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

ਕਿਉਂਕਿ ਇਸ ਸਮੇਂ ਅਜਿਹਾ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਪ੍ਰੋਟੋਕੋਲਾਂ ਨੂੰ ਮਿਲਾਉਣਾ ਸਮਝਦਾਰੀ ਹੈ ਜਿਹਨਾਂ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ ਨਹੀਂ ਹਨ। ਇਸ ਲਈ, ਇੱਕ ਸੰਭਾਵੀ ਹੱਲ ਦੋ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦੇ ਸੁਮੇਲ 'ਤੇ ਅਧਾਰਤ ਹੈ ਜੋ ਇੱਕੋ ਆਰਕੀਟੈਕਚਰਲ ਸ਼ੈਲੀ, REST HTTP ਅਤੇ CoAP ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਨ। ਇੱਕ ਹੋਰ ਪ੍ਰਸਤਾਵਿਤ ਹੱਲ ਦੋ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦੇ ਸੁਮੇਲ 'ਤੇ ਅਧਾਰਤ ਹੈ ਜੋ ਪਬਲਿਸ਼-ਸਬਸਕ੍ਰਾਈਬ ਇੰਟਰੈਕਸ਼ਨ, MQTT ਅਤੇ AMQP ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ। ਸਮਾਨ ਸੰਕਲਪਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ (ਦੋਵੇਂ MQTT ਅਤੇ AMQP ਦਲਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, CoAP ਅਤੇ HTTP REST ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ) ਇਹਨਾਂ ਸੰਜੋਗਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ ਅਤੇ ਘੱਟ ਏਕੀਕਰਣ ਯਤਨਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਚਿੱਤਰ (a) ਦੋ ਬੇਨਤੀ-ਜਵਾਬ ਮਾਡਲ, HTTP ਅਤੇ CoAP, ਅਤੇ ਇੱਕ IoT-F2C ਹੱਲ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਸੰਭਾਵਿਤ ਪਲੇਸਮੈਂਟ ਦਿਖਾਉਂਦਾ ਹੈ। ਕਿਉਂਕਿ HTTP ਅੱਜ ਦੇ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਜਾਣੇ-ਪਛਾਣੇ ਅਤੇ ਅਪਣਾਏ ਗਏ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਇਸ ਲਈ ਇਹ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਦੂਜੇ ਮੈਸੇਜਿੰਗ ਪ੍ਰੋਟੋਕੋਲਾਂ ਦੁਆਰਾ ਬਦਲਿਆ ਜਾਵੇਗਾ। ਕਲਾਉਡ ਅਤੇ ਧੁੰਦ ਦੇ ਵਿਚਕਾਰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਡਿਵਾਈਸਾਂ ਦੀ ਨੁਮਾਇੰਦਗੀ ਕਰਨ ਵਾਲੇ ਨੋਡਾਂ ਵਿੱਚੋਂ, REST HTTP ਇੱਕ ਵਾਜਬ ਹੱਲ ਹੈ।

ਦੂਜੇ ਪਾਸੇ, ਸੀਮਤ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਵਾਲੇ ਡਿਵਾਈਸਾਂ ਲਈ ਜੋ ਧੁੰਦ ਅਤੇ IoT ਲੇਅਰਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਕਰਦੇ ਹਨ, CoAP ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਵਧੇਰੇ ਕੁਸ਼ਲ ਹੈ। CoAP ਦਾ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਅਸਲ ਵਿੱਚ HTTP ਨਾਲ ਇਸਦੀ ਅਨੁਕੂਲਤਾ ਹੈ ਕਿਉਂਕਿ ਦੋਵੇਂ ਪ੍ਰੋਟੋਕੋਲ REST ਸਿਧਾਂਤਾਂ 'ਤੇ ਅਧਾਰਤ ਹਨ।

ਚਿੱਤਰ (ਬੀ) ਇੱਕੋ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਦੋ ਪ੍ਰਕਾਸ਼ਿਤ-ਸਬਸਕ੍ਰਾਈਬ ਇੰਟਰੈਕਸ਼ਨ ਮਾਡਲ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ MQTT ਅਤੇ AMQP ਸ਼ਾਮਲ ਹਨ। ਹਾਲਾਂਕਿ ਕਲਪਨਾਤਮਕ ਤੌਰ 'ਤੇ ਦੋਵੇਂ ਪ੍ਰੋਟੋਕੋਲ ਐਬਸਟਰੈਕਸ਼ਨ ਦੇ ਹਰੇਕ ਪੱਧਰ 'ਤੇ ਨੋਡਾਂ ਵਿਚਕਾਰ ਸੰਚਾਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ, ਉਹਨਾਂ ਦੀ ਸਥਿਤੀ ਪ੍ਰਦਰਸ਼ਨ ਦੇ ਅਧਾਰ ਤੇ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। MQTT ਨੂੰ ਸੀਮਤ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਵਾਲੇ ਡਿਵਾਈਸਾਂ ਲਈ ਇੱਕ ਹਲਕੇ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਰੂਪ ਵਿੱਚ ਡਿਜ਼ਾਇਨ ਕੀਤਾ ਗਿਆ ਸੀ, ਇਸਲਈ ਇਸਨੂੰ IoT ਅਤੇ ਧੁੰਦ ਵਿਚਕਾਰ ਸੰਚਾਰ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। AMQP ਵਧੇਰੇ ਸ਼ਕਤੀਸ਼ਾਲੀ ਯੰਤਰਾਂ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ ਜੋ ਇਸਨੂੰ ਧੁੰਦ ਅਤੇ ਕਲਾਉਡ ਨੋਡਾਂ ਦੇ ਵਿਚਕਾਰ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਸਥਾਪਿਤ ਕਰੇਗਾ। IoT ਵਿੱਚ MQTT ਦੀ ਬਜਾਏ, ਤੁਸੀਂ XMPP ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਕਿਉਂਕਿ ਇਸਨੂੰ ਹਲਕਾ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਪਰ ਇਹ ਅਜਿਹੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਨਹੀਂ ਵਰਤੀ ਜਾਂਦੀ.

ਸਿੱਟਾ

ਇਹ ਸੰਭਾਵਨਾ ਨਹੀਂ ਹੈ ਕਿ ਵਿਚਾਰੇ ਗਏ ਪ੍ਰੋਟੋਕੋਲਾਂ ਵਿੱਚੋਂ ਇੱਕ ਸਿਸਟਮ ਵਿੱਚ ਸਾਰੇ ਸੰਚਾਰ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ, ਸੀਮਤ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਵਾਲੇ ਯੰਤਰਾਂ ਤੋਂ ਲੈ ਕੇ ਕਲਾਉਡ ਸਰਵਰਾਂ ਤੱਕ। ਅਧਿਐਨ ਨੇ ਦਿਖਾਇਆ ਹੈ ਕਿ ਦੋ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਜੋ ਡਿਵੈਲਪਰ ਅਕਸਰ ਵਰਤਦੇ ਹਨ MQTT ਅਤੇ RESTful HTTP ਹਨ. ਇਹ ਦੋ ਪ੍ਰੋਟੋਕੋਲ ਨਾ ਸਿਰਫ ਸਭ ਤੋਂ ਵੱਧ ਪਰਿਪੱਕ ਅਤੇ ਸਥਿਰ ਹਨ, ਬਲਕਿ ਬਹੁਤ ਸਾਰੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਸਫਲ ਲਾਗੂਕਰਨ ਅਤੇ ਔਨਲਾਈਨ ਸਰੋਤ ਵੀ ਸ਼ਾਮਲ ਹਨ।

ਇਸਦੀ ਸਥਿਰਤਾ ਅਤੇ ਸਧਾਰਨ ਸੰਰਚਨਾ ਦੇ ਕਾਰਨ, MQTT ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਹੈ ਜਿਸ ਨੇ ਸਮੇਂ ਦੇ ਨਾਲ ਇਸਦੀ ਬਿਹਤਰ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਸਾਬਤ ਕੀਤਾ ਹੈ ਜਦੋਂ ਸੀਮਤ ਡਿਵਾਈਸਾਂ ਦੇ ਨਾਲ IoT ਲੇਅਰ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਸਿਸਟਮ ਦੇ ਉਹਨਾਂ ਹਿੱਸਿਆਂ ਵਿੱਚ ਜਿੱਥੇ ਸੀਮਤ ਕਨੈਕਟੀਵਿਟੀ ਅਤੇ ਬੈਟਰੀ ਦੀ ਖਪਤ ਕੋਈ ਮੁੱਦਾ ਨਹੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ ਧੁੰਦ ਦੇ ਕੁਝ ਖੇਤਰ ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਕਲਾਉਡ ਕੰਪਿਊਟਿੰਗ, RESTful HTTP ਇੱਕ ਆਸਾਨ ਵਿਕਲਪ ਹੈ। CoAP ਨੂੰ ਵੀ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਇੱਕ IoT ਮੈਸੇਜਿੰਗ ਸਟੈਂਡਰਡ ਵਜੋਂ ਤੇਜ਼ੀ ਨਾਲ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਇਹ ਨੇੜਲੇ ਭਵਿੱਖ ਵਿੱਚ MQTT ਅਤੇ HTTP ਦੇ ਸਮਾਨ ਸਥਿਰਤਾ ਅਤੇ ਪਰਿਪੱਕਤਾ ਦੇ ਪੱਧਰ ਤੱਕ ਪਹੁੰਚ ਜਾਵੇਗਾ। ਪਰ ਮਿਆਰ ਹੁਣ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ, ਜੋ ਕਿ ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਅਨੁਕੂਲਤਾ ਮੁੱਦਿਆਂ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ.

ਤੁਸੀਂ ਬਲੌਗ 'ਤੇ ਹੋਰ ਕੀ ਪੜ੍ਹ ਸਕਦੇ ਹੋ? Cloud4Y

→ ਕੰਪਿਊਟਰ ਤੁਹਾਨੂੰ ਸੁਆਦੀ ਬਣਾ ਦੇਵੇਗਾ
→ AI ਅਫਰੀਕਾ ਦੇ ਜਾਨਵਰਾਂ ਦਾ ਅਧਿਐਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ
→ ਗਰਮੀ ਲਗਭਗ ਖਤਮ ਹੋ ਗਈ ਹੈ. ਇੱਥੇ ਲਗਭਗ ਕੋਈ ਅਣਲੀਕ ਡੇਟਾ ਨਹੀਂ ਬਚਿਆ ਹੈ
→ ਕਲਾਊਡ ਬੈਕਅੱਪ 'ਤੇ ਬਚਾਉਣ ਦੇ 4 ਤਰੀਕੇ
→ ਆਬਾਦੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਰੱਖਣ ਵਾਲੇ ਇੱਕ ਯੂਨੀਫਾਈਡ ਫੈਡਰਲ ਜਾਣਕਾਰੀ ਸਰੋਤ 'ਤੇ

ਸਾਡੇ ਲਈ ਗਾਹਕ ਬਣੋ ਤਾਰ-ਚੈਨਲ, ਤਾਂ ਜੋ ਅਗਲਾ ਲੇਖ ਨਾ ਭੁੱਲੋ! ਅਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਦੋ ਵਾਰ ਤੋਂ ਵੱਧ ਨਹੀਂ ਅਤੇ ਸਿਰਫ਼ ਕਾਰੋਬਾਰ 'ਤੇ ਲਿਖਦੇ ਹਾਂ।

ਸਰੋਤ: www.habr.com