ਹਾਲ ਹੀ ਵਿੱਚ, ਟੈਲੀਗ੍ਰਾਮ ਕਿੰਨਾ ਵਧੀਆ ਹੈ, ਡੂਰੋਵ ਭਰਾ ਨੈੱਟਵਰਕ ਸਿਸਟਮ ਬਣਾਉਣ ਵਿੱਚ ਕਿੰਨੇ ਹੁਸ਼ਿਆਰ ਅਤੇ ਤਜਰਬੇਕਾਰ ਹਨ, ਆਦਿ ਬਾਰੇ ਪੋਸਟਾਂ ਹੈਬਰੇ 'ਤੇ ਅਕਸਰ ਦਿਖਾਈ ਦੇਣੀਆਂ ਸ਼ੁਰੂ ਹੋ ਗਈਆਂ ਹਨ। ਉਸੇ ਸਮੇਂ, ਬਹੁਤ ਘੱਟ ਲੋਕਾਂ ਨੇ ਅਸਲ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਤਕਨੀਕੀ ਡਿਵਾਈਸ ਵਿੱਚ ਲੀਨ ਕਰ ਲਿਆ ਹੈ - ਵੱਧ ਤੋਂ ਵੱਧ, ਉਹ JSON 'ਤੇ ਅਧਾਰਤ ਇੱਕ ਕਾਫ਼ੀ ਸਧਾਰਨ (ਅਤੇ MTProto ਤੋਂ ਬਿਲਕੁਲ ਵੱਖਰੇ) Bot API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਸਿਰਫ਼ ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ। ਵਿਸ਼ਵਾਸ 'ਤੇ ਸਾਰੀਆਂ ਪ੍ਰਸ਼ੰਸਾ ਅਤੇ ਪੀਆਰ ਜੋ ਮੈਸੇਂਜਰ ਦੇ ਦੁਆਲੇ ਘੁੰਮਦੀਆਂ ਹਨ। ਲਗਭਗ ਡੇਢ ਸਾਲ ਪਹਿਲਾਂ, ਏਸ਼ੇਲੋਨ ਐਨਜੀਓ ਵੈਸੀਲੀ (ਬਦਕਿਸਮਤੀ ਨਾਲ, ਡਰਾਫਟ ਦੇ ਨਾਲ ਹੈਬਰੇ ਉੱਤੇ ਉਸਦਾ ਖਾਤਾ ਮਿਟਾਇਆ ਗਿਆ ਸੀ) ਵਿੱਚ ਮੇਰੇ ਸਹਿਯੋਗੀ ਨੇ ਪਰਲ ਵਿੱਚ ਸਕ੍ਰੈਚ ਤੋਂ ਆਪਣਾ ਟੈਲੀਗ੍ਰਾਮ ਕਲਾਇੰਟ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਹਨਾਂ ਲਾਈਨਾਂ ਦਾ ਲੇਖਕ ਸ਼ਾਮਲ ਹੋ ਗਿਆ। ਕਿਉਂ ਪਰਲ, ਕੁਝ ਤੁਰੰਤ ਪੁੱਛਣਗੇ? ਕਿਉਂਕਿ ਅਜਿਹੇ ਪ੍ਰੋਜੈਕਟ ਦੂਜੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹਨ।ਅਸਲ ਵਿੱਚ, ਇਹ ਬਿੰਦੂ ਨਹੀਂ ਹੈ, ਕੋਈ ਹੋਰ ਭਾਸ਼ਾ ਹੋ ਸਕਦੀ ਹੈ ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਹੈ ਤਿਆਰ ਲਾਇਬ੍ਰੇਰੀ, ਅਤੇ ਉਸ ਅਨੁਸਾਰ ਲੇਖਕ ਨੂੰ ਸਾਰੇ ਤਰੀਕੇ ਨਾਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਸਕ੍ਰੈਚ ਤੋਂ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕ੍ਰਿਪਟੋਗ੍ਰਾਫੀ ਭਰੋਸੇ ਦਾ ਮਾਮਲਾ ਹੈ, ਪਰ ਪੁਸ਼ਟੀ ਕਰੋ. ਸੁਰੱਖਿਆ ਦੇ ਉਦੇਸ਼ ਨਾਲ ਇੱਕ ਉਤਪਾਦ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਨਿਰਮਾਤਾ ਤੋਂ ਤਿਆਰ-ਕੀਤੀ ਲਾਇਬ੍ਰੇਰੀ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਅਤੇ ਇਸ 'ਤੇ ਅੰਨ੍ਹੇਵਾਹ ਭਰੋਸਾ ਨਹੀਂ ਕਰ ਸਕਦੇ (ਹਾਲਾਂਕਿ, ਇਹ ਦੂਜੇ ਭਾਗ ਲਈ ਇੱਕ ਵਿਸ਼ਾ ਹੈ)। ਇਸ ਸਮੇਂ, ਲਾਇਬ੍ਰੇਰੀ "ਔਸਤ" ਪੱਧਰ 'ਤੇ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦੀ ਹੈ (ਤੁਹਾਨੂੰ ਕੋਈ ਵੀ API ਬੇਨਤੀਆਂ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ)।

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

ਵਿਸ਼ਾ - ਸੂਚੀ:

• ਦਸਤਾਵੇਜ਼... ਇਹ ਮੌਜੂਦ ਹੈ, ਠੀਕ ਹੈ? ਕੀ ਇਹ ਸੱਚ ਹੈ?..
• ਇੱਕ ਨੌਜਵਾਨ ਲੇਖਕ ਦੇ ਰੂਪ ਵਿੱਚ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ?
• ਬਾਈਨਰੀ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ: TL (ਟਾਈਪ ਲੈਂਗੂਏਜ) ਅਤੇ ਇਸਦੀ ਸਕੀਮ, ਅਤੇ ਲੇਅਰਾਂ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡਰਾਉਣੇ ਸ਼ਬਦ
  • TL ਸੰਟੈਕਸ ਦੇ ਇੱਕ ਸਬਸੈੱਟ ਦਾ ਇੱਕ ਛੋਟਾ ਵੇਰਵਾ ਉਹਨਾਂ ਲਈ ਜੋ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਹਨ
  • ਵੈਕਟਰ, ਜੋ ਕਦੇ ਵੀ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ
  • ਕੋਡ ਵਿੱਚ ਮੌਜੂਦਾ TL ਲਾਗੂਕਰਨ
  • ਟਾਈਪ ਭਾਸ਼ਾ ਵਿੱਚ ਕਿਸਮਾਂ ਦੀ ਘਾਟ
  • ਸੰਸਕਰਣ. ਪਰਤਾਂ
• ਐਮਟੀਪੀਟਰੋ
  • ਆਵਾਜਾਈ ਪਰਤ
  • ਕੁੰਜੀਆਂ, ਸੁਨੇਹੇ, ਸੈਸ਼ਨ, ਡਿਫੀ-ਹੇਲਮੈਨ
  • ਸੁਨੇਹੇ ਸੁਨੇਹੇ, msg_id, msg_seqno, ਪੁਸ਼ਟੀਕਰਨ, ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਪਿੰਗ ਅਤੇ ਹੋਰ ਮੁਹਾਵਰੇ
    • RPC: ਬੇਨਤੀਆਂ, ਜਵਾਬ, ਤਰੁੱਟੀਆਂ। ਪੁਸ਼ਟੀਕਰਨ।
    • ਨਸ਼ਾਖੋਰੀ: ਸੁਨੇਹਾ ਸਥਿਤੀਆਂ
    • ਪਿੰਗ ਅਤੇ ਸਮਾਂ। ਕਤਾਰਾਂ।
    • ਇਸ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ?
• API?
• ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ!

ਦਸਤਾਵੇਜ਼... ਇਹ ਮੌਜੂਦ ਹੈ, ਠੀਕ ਹੈ? ਕੀ ਇਹ ਸੱਚ ਹੈ?..

ਇਸ ਲੇਖ ਲਈ ਨੋਟਾਂ ਦੇ ਟੁਕੜੇ ਪਿਛਲੀਆਂ ਗਰਮੀਆਂ ਵਿੱਚ ਇਕੱਠੇ ਕੀਤੇ ਜਾਣੇ ਸ਼ੁਰੂ ਹੋ ਗਏ ਸਨ। ਇਹ ਸਾਰਾ ਸਮਾਂ ਸਰਕਾਰੀ ਵੈਬਸਾਈਟ 'ਤੇ https://core.telegram.org ਦਸਤਾਵੇਜ਼ ਲੇਅਰ 23 ਦੇ ਰੂਪ ਵਿੱਚ ਸੀ, ਯਾਨੀ. 2014 ਵਿੱਚ ਕਿਤੇ ਫਸ ਗਿਆ ਸੀ (ਯਾਦ ਰੱਖੋ, ਉਦੋਂ ਵੀ ਚੈਨਲ ਨਹੀਂ ਸਨ?) ਬੇਸ਼ੱਕ, ਸਿਧਾਂਤ ਵਿੱਚ, ਇਸ ਨਾਲ ਸਾਨੂੰ 2014 ਵਿੱਚ ਉਸ ਸਮੇਂ ਕਾਰਜਕੁਸ਼ਲਤਾ ਵਾਲੇ ਇੱਕ ਕਲਾਇੰਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੋਣੀ ਚਾਹੀਦੀ ਸੀ। ਪਰ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਵੀ, ਦਸਤਾਵੇਜ਼, ਪਹਿਲਾਂ, ਅਧੂਰਾ, ਅਤੇ ਦੂਜਾ, ਸਥਾਨਾਂ ਵਿੱਚ ਇਹ ਆਪਣੇ ਆਪ ਦੇ ਉਲਟ ਸੀ। ਸਿਰਫ਼ ਇੱਕ ਮਹੀਨਾ ਪਹਿਲਾਂ, ਸਤੰਬਰ 2019 ਵਿੱਚ, ਇਹ ਸੀ ਅਚਾਨਕ ਇਹ ਖੋਜ ਕੀਤੀ ਗਈ ਸੀ ਕਿ ਸਾਈਟ 'ਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦਾ ਇੱਕ ਵੱਡਾ ਅਪਡੇਟ ਸੀ, ਬਿਲਕੁਲ ਤਾਜ਼ਾ ਲੇਅਰ 105 ਲਈ, ਇੱਕ ਨੋਟ ਦੇ ਨਾਲ ਕਿ ਹੁਣ ਹਰ ਚੀਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਦਰਅਸਲ, ਬਹੁਤ ਸਾਰੇ ਲੇਖ ਸੰਸ਼ੋਧਿਤ ਕੀਤੇ ਗਏ ਸਨ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਨਾ ਬਦਲੇ ਗਏ ਸਨ। ਇਸ ਲਈ, ਦਸਤਾਵੇਜ਼ਾਂ ਬਾਰੇ ਹੇਠਾਂ ਦਿੱਤੀ ਆਲੋਚਨਾ ਨੂੰ ਪੜ੍ਹਦੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਚੀਜ਼ਾਂ ਹੁਣ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ, ਪਰ ਕੁਝ ਅਜੇ ਵੀ ਕਾਫ਼ੀ ਹਨ. ਆਖ਼ਰਕਾਰ, ਆਧੁਨਿਕ ਸੰਸਾਰ ਵਿੱਚ 5 ਸਾਲ ਸਿਰਫ਼ ਇੱਕ ਲੰਮਾ ਸਮਾਂ ਨਹੀਂ ਹੈ, ਪਰ ਬਹੁਤ ਹੀ ਬਹੁਤ ਬਹੁਤ ਸਾਰੇ. ਉਹਨਾਂ ਸਮਿਆਂ ਤੋਂ (ਖਾਸ ਤੌਰ 'ਤੇ ਜੇ ਤੁਸੀਂ ਉਦੋਂ ਤੋਂ ਰੱਦ ਕੀਤੀਆਂ ਅਤੇ ਮੁੜ ਸੁਰਜੀਤ ਕੀਤੀਆਂ ਜੀਓਚੈਟ ਸਾਈਟਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦੇ), ਸਕੀਮ ਵਿੱਚ API ਵਿਧੀਆਂ ਦੀ ਗਿਣਤੀ ਸੌ ਤੋਂ ਵੱਧ ਕੇ ਢਾਈ ਸੌ ਤੋਂ ਵੱਧ ਹੋ ਗਈ ਹੈ!

ਇੱਕ ਨੌਜਵਾਨ ਲੇਖਕ ਦੇ ਰੂਪ ਵਿੱਚ ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ?

ਇਸ ਨਾਲ ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਤੁਸੀਂ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਦੇ ਹੋ ਜਾਂ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਰੈਡੀਮੇਡ ਲਾਇਬ੍ਰੇਰੀਆਂ ਪਾਈਥਨ ਲਈ ਟੈਲੀਥੌਨ ਜ PHP ਲਈ ਮੇਡਲਾਈਨ, ਕਿਸੇ ਵੀ ਹਾਲਤ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਲੋੜ ਹੋਵੇਗੀ ਆਪਣੀ ਅਰਜ਼ੀ ਰਜਿਸਟਰ ਕਰੋ - ਪੈਰਾਮੀਟਰ ਪ੍ਰਾਪਤ ਕਰੋ api_id и api_hash (ਜਿਨ੍ਹਾਂ ਨੇ VKontakte API ਨਾਲ ਕੰਮ ਕੀਤਾ ਹੈ ਉਹ ਤੁਰੰਤ ਸਮਝ ਜਾਂਦੇ ਹਨ) ਜਿਸ ਦੁਆਰਾ ਸਰਵਰ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪਛਾਣ ਕਰੇਗਾ। ਇਹ ਕਰਨਾ ਪਏਗਾ ਇਹ ਕਾਨੂੰਨੀ ਕਾਰਨਾਂ ਕਰਕੇ ਕਰੋ, ਪਰ ਅਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਗੱਲ ਕਰਾਂਗੇ ਕਿ ਲਾਇਬ੍ਰੇਰੀ ਲੇਖਕ ਇਸਨੂੰ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਕਿਉਂ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹਨ। ਤੁਸੀਂ ਟੈਸਟ ਦੇ ਮੁੱਲਾਂ ਤੋਂ ਸੰਤੁਸ਼ਟ ਹੋ ਸਕਦੇ ਹੋ, ਹਾਲਾਂਕਿ ਉਹ ਬਹੁਤ ਸੀਮਤ ਹਨ - ਤੱਥ ਇਹ ਹੈ ਕਿ ਹੁਣ ਤੁਸੀਂ ਰਜਿਸਟਰ ਕਰ ਸਕਦੇ ਹੋ ਸਿਰਫ ਇੱਕ ਐਪ, ਇਸ ਲਈ ਇਸ ਵਿੱਚ ਜਲਦਬਾਜ਼ੀ ਨਾ ਕਰੋ।

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

ਅਤੇ ਜੇ ਤੁਸੀਂ ਸਕ੍ਰੈਚ ਤੋਂ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਪੈਰਾਮੀਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਸਲ ਵਿੱਚ ਅਜੇ ਵੀ ਬਹੁਤ ਦੂਰ ਹੈ. ਹਾਲਾਂਕਿ https://core.telegram.org/ ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸ਼ੁਰੂ ਕਰਨ ਵਿੱਚ ਉਹਨਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਪਹਿਲਾਂ ਲਾਗੂ ਕਰਨਾ ਹੋਵੇਗਾ MTProto ਪ੍ਰੋਟੋਕੋਲ - ਪਰ ਜੇ ਤੁਸੀਂ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹੋ OSI ਮਾਡਲ ਦੇ ਅਨੁਸਾਰ ਲੇਆਉਟ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਇੱਕ ਆਮ ਵਰਣਨ ਲਈ ਪੰਨੇ ਦੇ ਅੰਤ ਵਿੱਚ, ਫਿਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਿਅਰਥ ਹੈ.

ਵਾਸਤਵ ਵਿੱਚ, MTProto ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਵਿੱਚ, ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਪੱਧਰਾਂ 'ਤੇ (ਜਿਵੇਂ ਕਿ OS ਕਰਨਲ ਵਿੱਚ ਕੰਮ ਕਰਦੇ ਵਿਦੇਸ਼ੀ ਨੈੱਟਵਰਕਰ ਕਹਿੰਦੇ ਹਨ, ਲੇਅਰ ਉਲੰਘਣਾ), ਇੱਕ ਵੱਡਾ, ਦਰਦਨਾਕ ਅਤੇ ਭਿਆਨਕ ਵਿਸ਼ਾ ਰਸਤੇ ਵਿੱਚ ਆ ਜਾਵੇਗਾ ...

ਬਾਈਨਰੀ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ: TL (ਟਾਈਪ ਲੈਂਗੂਏਜ) ਅਤੇ ਇਸਦੀ ਸਕੀਮ, ਅਤੇ ਲੇਅਰਾਂ, ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਡਰਾਉਣੇ ਸ਼ਬਦ

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

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

int ? = Int;
long ? = Long;
double ? = Double;
string ? = String;

vector#1cb5c415 {t:Type} # [ t ] = Vector t;

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

rpc_answer_unknown#5e2ad36e = RpcDropAnswer;
rpc_answer_dropped_running#cd78e586 = RpcDropAnswer;
rpc_answer_dropped#a43ad8b7 msg_id:long seq_no:int bytes:int = RpcDropAnswer;

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

---functions---

set_client_DH_params#f5045f1f nonce:int128 server_nonce:int128 encrypted_data:bytes = Set_client_DH_params_answer;

ping#7abe77ec ping_id:long = Pong;
ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

invokeAfterMsg#cb9f372d msg_id:long query:!X = X;
invokeAfterMsgs#3dc4b4f0 msg_ids:Vector<long> query:!X = X;

account.updateProfile#78515775 flags:# first_name:flags.0?string last_name:flags.1?string about:flags.2?string = User;
account.sendChangePhoneCode#8e57deb flags:# allow_flashcall:flags.0?true phone_number:string current_number:flags.0?Bool = auth.SentCode;

ਇਸ ਨੂੰ ਪਹਿਲੀ ਵਾਰ ਦੇਖਣ ਵਾਲਾ ਵਿਅਕਤੀ ਅਨੁਭਵੀ ਤੌਰ 'ਤੇ ਜੋ ਲਿਖਿਆ ਗਿਆ ਹੈ ਉਸ ਦੇ ਸਿਰਫ ਹਿੱਸੇ ਨੂੰ ਪਛਾਣਨ ਦੇ ਯੋਗ ਹੋਵੇਗਾ - ਠੀਕ ਹੈ, ਇਹ ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ ਬਣਤਰ ਹਨ (ਹਾਲਾਂਕਿ ਨਾਮ ਕਿੱਥੇ ਹੈ, ਖੱਬੇ ਪਾਸੇ ਜਾਂ ਸੱਜੇ ਪਾਸੇ?), ਉਨ੍ਹਾਂ ਵਿੱਚ ਖੇਤਰ ਹਨ, ਜਿਸਦੇ ਬਾਅਦ ਇੱਕ ਕੌਲਨ ਤੋਂ ਬਾਅਦ ਇੱਕ ਕਿਸਮ ਆਉਂਦੀ ਹੈ... ਸ਼ਾਇਦ। ਇੱਥੇ ਕੋਣ ਬਰੈਕਟਾਂ ਵਿੱਚ ਸ਼ਾਇਦ ਟੈਂਪਲੇਟਸ ਹਨ ਜਿਵੇਂ ਕਿ C++ (ਅਸਲ ਵਿੱਚ, ਸਚਮੁਚ ਨਹੀਂ). ਅਤੇ ਹੋਰ ਸਾਰੇ ਚਿੰਨ੍ਹਾਂ ਦਾ ਕੀ ਅਰਥ ਹੈ, ਪ੍ਰਸ਼ਨ ਚਿੰਨ੍ਹ, ਵਿਸਮਿਕ ਚਿੰਨ੍ਹ, ਪ੍ਰਤੀਸ਼ਤ, ਹੈਸ਼ ਚਿੰਨ੍ਹ (ਅਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਉਨ੍ਹਾਂ ਦਾ ਅਰਥ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਵੱਖੋ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ), ਕਈ ਵਾਰ ਮੌਜੂਦ ਹਨ ਅਤੇ ਕਦੇ ਨਹੀਂ, ਹੈਕਸਾਡੈਸੀਮਲ ਨੰਬਰ - ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇਸ ਤੋਂ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ ਸਹੀ (ਜਿਸ ਨੂੰ ਸਰਵਰ ਦੁਆਰਾ ਰੱਦ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ) ਬਾਈਟ ਸਟ੍ਰੀਮ? ਤੁਹਾਨੂੰ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹਨਾ ਹੋਵੇਗਾ (ਹਾਂ, ਨੇੜੇ ਦੇ JSON ਸੰਸਕਰਣ ਵਿੱਚ ਸਕੀਮਾ ਦੇ ਲਿੰਕ ਹਨ - ਪਰ ਇਹ ਇਸਨੂੰ ਹੋਰ ਸਪੱਸ਼ਟ ਨਹੀਂ ਕਰਦਾ).

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

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

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

ਜਿਵੇਂ ਕਿਹਾ ਗਿਆ ਹੈ ਲਿਓਨੇਰਡ ਚੈਨਲ 'ਤੇ #perl ਫ੍ਰੀਨੋਡ ਆਈਆਰਸੀ ਨੈਟਵਰਕ ਵਿੱਚ, ਜਿਸ ਨੇ ਟੈਲੀਗ੍ਰਾਮ ਤੋਂ ਮੈਟ੍ਰਿਕਸ ਤੱਕ ਇੱਕ ਗੇਟ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ (ਕੋਟ ਦਾ ਅਨੁਵਾਦ ਮੈਮੋਰੀ ਤੋਂ ਗਲਤ ਹੈ):

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

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

ਪਰ ਅੱਗੇ

TL ਸੰਟੈਕਸ ਦੇ ਸਬਸੈੱਟ ਦਾ ਇੱਕ ਛੋਟਾ ਵੇਰਵਾ ਉਹਨਾਂ ਲਈ ਜੋ ਅਧਿਕਾਰਤ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਨਹੀਂ ਪੜ੍ਹਦੇ ਹਨ

constructor = Type;
myVec ids:Vector<long> = Type;

fixed#abcdef34 id:int = Type2;

fixedVec set:Vector<Type2> = FixedVec;

constructorOne#crc32 field1:int = PolymorType;
constructorTwo#2crc32 field_a:long field_b:Type3 field_c:int = PolymorType;
constructorThree#deadcrc bit_flags_of_what_really_present:# optional_field4:bit_flags_of_what_really_present.1?Type = PolymorType;

an_id#12abcd34 id:int = Type3;
a_null#6789cdef = Type3;

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

ਜੇਕਰ ਪਰਿਭਾਸ਼ਾ ਲਾਈਨ ਤੋਂ ਬਾਅਦ ਹੁੰਦੀ ਹੈ ---functions---, ਤਾਂ ਸੰਟੈਕਸ ਇੱਕੋ ਜਿਹਾ ਰਹੇਗਾ, ਪਰ ਅਰਥ ਵੱਖਰਾ ਹੋਵੇਗਾ: ਕੰਸਟਰਕਟਰ RPC ਫੰਕਸ਼ਨ ਦਾ ਨਾਮ ਬਣ ਜਾਵੇਗਾ, ਖੇਤਰ ਪੈਰਾਮੀਟਰ ਬਣ ਜਾਣਗੇ (ਠੀਕ ਹੈ, ਯਾਨੀ, ਇਹ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਹੀ ਰਹੇਗਾ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦੱਸਿਆ ਗਿਆ ਹੈ। , ਇਹ ਸਿਰਫ਼ ਨਿਰਧਾਰਤ ਅਰਥ ਹੋਵੇਗਾ), ਅਤੇ "ਪੋਲੀਮੋਰਫਿਕ ਕਿਸਮ " - ਵਾਪਸ ਕੀਤੇ ਨਤੀਜੇ ਦੀ ਕਿਸਮ। ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਹ ਅਜੇ ਵੀ ਬਹੁਰੂਪੀ ਰਹੇਗਾ - ਸਿਰਫ਼ ਭਾਗ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ---types---, ਪਰ ਇਸ ਕੰਸਟਰਕਟਰ ਨੂੰ "ਵਿਚਾਰਿਆ ਨਹੀਂ ਜਾਵੇਗਾ"। ਉਹਨਾਂ ਦੇ ਆਰਗੂਮੈਂਟਾਂ ਦੁਆਰਾ ਬੁਲਾਏ ਗਏ ਫੰਕਸ਼ਨਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਨੂੰ ਓਵਰਲੋਡ ਕਰਨਾ, ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ, ਇੱਕੋ ਨਾਮ ਵਾਲੇ ਪਰ ਵੱਖ-ਵੱਖ ਦਸਤਖਤਾਂ ਵਾਲੇ ਕਈ ਫੰਕਸ਼ਨ, ਜਿਵੇਂ ਕਿ C++ ਵਿੱਚ, TL ਵਿੱਚ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤੇ ਗਏ ਹਨ।

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

ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ? ਡੀਸੀਰੀਅਲਾਈਜ਼ਰ, ਜੋ ਹਮੇਸ਼ਾ 4 ਬਾਈਟ ਪੜ੍ਹਦਾ ਹੈ, ਮੁੱਲ ਨੂੰ ਦੇਖਦਾ ਹੈ 0xcrc32 - ਅਤੇ ਸਮਝਦਾ ਹੈ ਕਿ ਅੱਗੇ ਕੀ ਹੋਵੇਗਾ field1 ਕਿਸਮ ਦੇ ਨਾਲ int, i.e. ਬਿਲਕੁਲ 4 ਬਾਈਟ ਪੜ੍ਹਦਾ ਹੈ, ਇਸ 'ਤੇ ਟਾਈਪ ਦੇ ਨਾਲ ਓਵਰਲਾਈੰਗ ਫੀਲਡ PolymorType ਪੜ੍ਹੋ। ਨੂੰ ਵੇਖਦਾ ਹੈ 0x2crc32 ਅਤੇ ਸਮਝਦਾ ਹੈ ਕਿ ਅੱਗੇ ਦੋ ਖੇਤਰ ਹਨ, ਪਹਿਲਾਂ long, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸੀਂ 8 ਬਾਈਟ ਪੜ੍ਹਦੇ ਹਾਂ। ਅਤੇ ਫਿਰ ਦੁਬਾਰਾ ਇੱਕ ਗੁੰਝਲਦਾਰ ਕਿਸਮ, ਜੋ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਡੀਸੀਰੀਅਲਾਈਜ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ. ਉਦਾਹਰਣ ਲਈ, Type3 ਸਰਕਟ ਵਿੱਚ ਕ੍ਰਮਵਾਰ ਦੋ ਕੰਸਟਰਕਟਰਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਜਾਂ ਤਾਂ ਮਿਲਣਾ ਚਾਹੀਦਾ ਹੈ 0x12abcd34, ਜਿਸ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ 4 ਹੋਰ ਬਾਈਟਸ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ int, ਜਾਂ 0x6789cdef, ਜਿਸ ਤੋਂ ਬਾਅਦ ਕੁਝ ਨਹੀਂ ਹੋਵੇਗਾ। ਹੋਰ ਕੁਝ ਵੀ - ਤੁਹਾਨੂੰ ਇੱਕ ਅਪਵਾਦ ਸੁੱਟਣ ਦੀ ਲੋੜ ਹੈ. ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਇਸ ਤੋਂ ਬਾਅਦ ਅਸੀਂ 4 ਬਾਈਟਸ ਨੂੰ ਪੜ੍ਹਨ ਲਈ ਵਾਪਸ ਜਾਂਦੇ ਹਾਂ int ਖੇਤਰ field_c в constructorTwo ਅਤੇ ਇਸਦੇ ਨਾਲ ਅਸੀਂ ਆਪਣਾ ਪੜ੍ਹਨਾ ਖਤਮ ਕਰਦੇ ਹਾਂ PolymorType.

ਅੰਤ ਵਿੱਚ, ਜੇ ਤੁਸੀਂ ਫੜੇ ਜਾਂਦੇ ਹੋ 0xdeadcrc ਨੂੰ constructorThree, ਫਿਰ ਸਭ ਕੁਝ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਾਡਾ ਪਹਿਲਾ ਖੇਤਰ ਹੈ bit_flags_of_what_really_present ਕਿਸਮ ਦੇ ਨਾਲ # - ਅਸਲ ਵਿੱਚ, ਇਹ ਕਿਸਮ ਲਈ ਸਿਰਫ਼ ਇੱਕ ਉਪਨਾਮ ਹੈ nat, ਭਾਵ "ਕੁਦਰਤੀ ਸੰਖਿਆ"। ਇਹ, ਅਸਲ ਵਿੱਚ, ਅਣ-ਹਸਤਾਖਰਿਤ ਇੰਟ ਹੈ, ਵੈਸੇ, ਇੱਕੋ ਇੱਕ ਕੇਸ ਹੈ ਜਦੋਂ ਹਸਤਾਖਰਿਤ ਸੰਖਿਆਵਾਂ ਅਸਲ ਸਰਕਟਾਂ ਵਿੱਚ ਵਾਪਰਦੀਆਂ ਹਨ। ਇਸ ਲਈ, ਅਗਲਾ ਇੱਕ ਪ੍ਰਸ਼ਨ ਚਿੰਨ੍ਹ ਵਾਲਾ ਨਿਰਮਾਣ ਹੈ, ਮਤਲਬ ਕਿ ਇਹ ਫੀਲਡ - ਇਹ ਤਾਰ 'ਤੇ ਸਿਰਫ ਤਾਂ ਹੀ ਮੌਜੂਦ ਹੋਵੇਗਾ ਜੇਕਰ ਸਬੰਧਤ ਬਿੱਟ ਨੂੰ ਸੰਦਰਭਿਤ ਖੇਤਰ ਵਿੱਚ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ (ਲਗਭਗ ਇੱਕ ਟਰਨਰੀ ਓਪਰੇਟਰ ਵਾਂਗ)। ਇਸ ਲਈ, ਮੰਨ ਲਓ ਕਿ ਇਹ ਬਿੱਟ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਸੀ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅੱਗੇ ਸਾਨੂੰ ਇੱਕ ਖੇਤਰ ਨੂੰ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਹੈ ਜਿਵੇਂ ਕਿ Type, ਜਿਸ ਵਿੱਚ ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ 2 ਕੰਸਟਰਕਟਰ ਹਨ। ਇੱਕ ਖਾਲੀ ਹੈ (ਸਿਰਫ਼ ਪਛਾਣਕਰਤਾ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ), ਦੂਜੇ ਵਿੱਚ ਇੱਕ ਖੇਤਰ ਹੈ ids ਕਿਸਮ ਦੇ ਨਾਲ ids:Vector<long>.

ਤੁਸੀਂ ਸੋਚ ਸਕਦੇ ਹੋ ਕਿ ਟੈਂਪਲੇਟ ਅਤੇ ਜੈਨਰਿਕ ਦੋਵੇਂ ਪ੍ਰੋ ਜਾਂ ਜਾਵਾ ਵਿੱਚ ਹਨ। ਪਰ ਨਹੀਂ। ਲਗਭਗ. ਇਹ ਕੇਵਲ ਇਕੋ ਅਸਲ ਸਰਕਟਾਂ ਵਿੱਚ ਕੋਣ ਬਰੈਕਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਮਾਮਲਾ, ਅਤੇ ਇਹ ਸਿਰਫ਼ ਵੈਕਟਰ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਬਾਈਟ ਸਟ੍ਰੀਮ ਵਿੱਚ, ਇਹ ਵੈਕਟਰ ਕਿਸਮ ਲਈ 4 CRC32 ਬਾਈਟ ਹੋਣਗੇ, ਹਮੇਸ਼ਾ ਇੱਕੋ ਜਿਹੇ, ਫਿਰ 4 ਬਾਈਟ - ਐਰੇ ਤੱਤਾਂ ਦੀ ਗਿਣਤੀ, ਅਤੇ ਫਿਰ ਇਹ ਤੱਤ ਆਪਣੇ ਆਪ।

ਇਸ ਤੱਥ ਨੂੰ ਜੋੜੋ ਕਿ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਹਮੇਸ਼ਾ 4 ਬਾਈਟਾਂ ਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਹੁੰਦੀ ਹੈ, ਸਾਰੀਆਂ ਕਿਸਮਾਂ ਇਸਦੇ ਗੁਣਜ ਹੁੰਦੀਆਂ ਹਨ - ਬਿਲਟ-ਇਨ ਕਿਸਮਾਂ ਦਾ ਵੀ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ bytes и string ਲੰਬਾਈ ਦੇ ਮੈਨੂਅਲ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ 4 ਦੁਆਰਾ ਇਸ ਅਲਾਈਨਮੈਂਟ ਨਾਲ - ਠੀਕ ਹੈ, ਇਹ ਆਮ ਅਤੇ ਮੁਕਾਬਲਤਨ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਵੀ ਜਾਪਦਾ ਹੈ? ਹਾਲਾਂਕਿ TL ਨੂੰ ਇੱਕ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਾਈਨਰੀ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਹੋਣ ਦਾ ਦਾਅਵਾ ਕੀਤਾ ਗਿਆ ਹੈ, ਉਹਨਾਂ ਦੇ ਨਾਲ ਨਰਕ ਵਿੱਚ, ਸਿਰਫ ਲਗਭਗ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਦੇ ਵਿਸਥਾਰ ਦੇ ਨਾਲ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਬੁਲੀਅਨ ਮੁੱਲਾਂ ਅਤੇ ਸਿੰਗਲ-ਅੱਖਰ ਸਤਰ ਨੂੰ 4 ਬਾਈਟ ਤੱਕ, ਕੀ JSON ਅਜੇ ਵੀ ਬਹੁਤ ਮੋਟਾ ਹੋਵੇਗਾ? ਦੇਖੋ, ਬੇਲੋੜੇ ਖੇਤਰਾਂ ਨੂੰ ਵੀ ਬਿੱਟ ਫਲੈਗ ਦੁਆਰਾ ਛੱਡਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਅਤੇ ਭਵਿੱਖ ਲਈ ਵੀ ਵਿਸਤ੍ਰਿਤ ਹੈ, ਤਾਂ ਕਿਉਂ ਨਾ ਬਾਅਦ ਵਿੱਚ ਕੰਸਟਰਕਟਰ ਵਿੱਚ ਨਵੇਂ ਵਿਕਲਪਿਕ ਖੇਤਰਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾਵੇ?...

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

ਦੂਜਾ, ਆਓ ਯਾਦ ਕਰੀਏ ਸੀ ਆਰ ਸੀ 32, ਜੋ ਕਿ ਇੱਥੇ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਗਿਆ ਹੈ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਵਿਲੱਖਣ ਤੌਰ 'ਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਿ ਕਿਹੜੀ ਕਿਸਮ (ਡੀ) ਸੀਰੀਅਲਾਈਜ਼ ਕੀਤੀ ਜਾ ਰਹੀ ਹੈ। ਇੱਥੇ ਸਾਨੂੰ ਟੱਕਰਾਂ ਦੀ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ - ਅਤੇ ਨਹੀਂ, ਸੰਭਾਵਨਾ 232 ਵਿੱਚ ਇੱਕ ਨਹੀਂ ਹੈ, ਪਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ. ਕਿਸ ਨੂੰ ਯਾਦ ਹੈ ਕਿ CRC32 ਸੰਚਾਰ ਚੈਨਲ ਵਿੱਚ ਗਲਤੀਆਂ ਦਾ ਪਤਾ ਲਗਾਉਣ (ਅਤੇ ਠੀਕ) ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਅਤੇ ਇਸਦੇ ਅਨੁਸਾਰ ਇਹਨਾਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦੂਜਿਆਂ ਦੇ ਨੁਕਸਾਨ ਲਈ ਸੁਧਾਰਦਾ ਹੈ? ਉਦਾਹਰਨ ਲਈ, ਇਹ ਬਾਈਟਾਂ ਨੂੰ ਮੁੜ ਵਿਵਸਥਿਤ ਕਰਨ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ: ਜੇਕਰ ਤੁਸੀਂ ਦੋ ਲਾਈਨਾਂ ਤੋਂ CRC32 ਦੀ ਗਣਨਾ ਕਰਦੇ ਹੋ, ਤਾਂ ਦੂਜੀ ਵਿੱਚ ਤੁਸੀਂ ਅਗਲੇ 4 ਬਾਈਟਾਂ ਨਾਲ ਪਹਿਲੇ 4 ਬਾਈਟਾਂ ਨੂੰ ਸਵੈਪ ਕਰਦੇ ਹੋ - ਇਹ ਉਹੀ ਹੋਵੇਗਾ। ਜਦੋਂ ਸਾਡਾ ਇਨਪੁਟ ਲਾਤੀਨੀ ਵਰਣਮਾਲਾ (ਅਤੇ ਥੋੜਾ ਜਿਹਾ ਵਿਰਾਮ ਚਿੰਨ੍ਹ) ਤੋਂ ਟੈਕਸਟ ਸਤਰ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਨਾਮ ਖਾਸ ਤੌਰ 'ਤੇ ਬੇਤਰਤੀਬ ਨਹੀਂ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਅਜਿਹੇ ਪੁਨਰ-ਵਿਵਸਥਾ ਦੀ ਸੰਭਾਵਨਾ ਬਹੁਤ ਵਧ ਜਾਂਦੀ ਹੈ।

ਤਰੀਕੇ ਨਾਲ, ਕਿਸ ਨੇ ਜਾਂਚ ਕੀਤੀ ਕਿ ਉੱਥੇ ਕੀ ਸੀ? ਅਸਲ ਵਿੱਚ CRC32? ਸ਼ੁਰੂਆਤੀ ਸਰੋਤ ਕੋਡਾਂ ਵਿੱਚੋਂ ਇੱਕ (ਵਾਲਟਮੈਨ ਤੋਂ ਪਹਿਲਾਂ ਵੀ) ਵਿੱਚ ਇੱਕ ਹੈਸ਼ ਫੰਕਸ਼ਨ ਸੀ ਜੋ ਹਰੇਕ ਅੱਖਰ ਨੂੰ 239 ਨੰਬਰ ਨਾਲ ਗੁਣਾ ਕਰਦਾ ਸੀ, ਇਹਨਾਂ ਲੋਕਾਂ ਦੁਆਰਾ ਬਹੁਤ ਪਿਆਰਾ, ਹਾ ਹਾ!

ਅੰਤ ਵਿੱਚ, ਠੀਕ ਹੈ, ਅਸੀਂ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਇੱਕ ਫੀਲਡ ਕਿਸਮ ਦੇ ਨਾਲ ਕੰਸਟਰਕਟਰ Vector<int> и Vector<PolymorType> ਵੱਖਰਾ CRC32 ਹੋਵੇਗਾ। ਔਨਲਾਈਨ ਪ੍ਰਦਰਸ਼ਨ ਬਾਰੇ ਕੀ? ਅਤੇ ਸਿਧਾਂਤਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਕੀ ਇਹ ਕਿਸਮ ਦਾ ਹਿੱਸਾ ਬਣ ਜਾਂਦਾ ਹੈ? ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਦਸ ਹਜ਼ਾਰ ਸੰਖਿਆਵਾਂ ਦੀ ਇੱਕ ਐਰੇ ਪਾਸ ਕਰਦੇ ਹਾਂ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਾਲ Vector<int> ਸਭ ਕੁਝ ਸਪਸ਼ਟ ਹੈ, ਲੰਬਾਈ ਅਤੇ ਹੋਰ 40000 ਬਾਈਟ। ਕੀ ਜੇ ਇਹ Vector<Type2>, ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਖੇਤਰ ਸ਼ਾਮਲ ਹੈ int ਅਤੇ ਇਹ ਕਿਸਮ ਵਿੱਚ ਇਕੱਲਾ ਹੈ - ਕੀ ਸਾਨੂੰ 10000xabcdef0 ਨੂੰ 34 ਵਾਰ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਫਿਰ 4 ਬਾਈਟਸ int, ਜਾਂ ਭਾਸ਼ਾ ਸਾਡੇ ਲਈ ਇਸਨੂੰ ਕੰਸਟਰਕਟਰ ਤੋਂ ਆਜ਼ਾਦ ਕਰਨ ਦੇ ਯੋਗ ਹੈ fixedVec ਅਤੇ 80000 ਬਾਈਟਾਂ ਦੀ ਬਜਾਏ, ਸਿਰਫ 40000 ਨੂੰ ਦੁਬਾਰਾ ਟ੍ਰਾਂਸਫਰ ਕਰੋ?

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

ਇਸ ਲਈ…

ਵੈਕਟਰ, ਜੋ ਕਦੇ ਵੀ ਜਾਰੀ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ

ਜੇਕਰ ਤੁਸੀਂ ਕੰਬੀਨੇਟਰਾਂ ਦੇ ਵਰਣਨ ਦੇ ਪੰਨਿਆਂ ਨੂੰ ਘੁੰਮਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਦੇਖੋਗੇ ਕਿ ਇੱਕ ਵੈਕਟਰ (ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਇੱਕ ਮੈਟ੍ਰਿਕਸ ਵੀ) ਰਸਮੀ ਤੌਰ 'ਤੇ ਕਈ ਸ਼ੀਟਾਂ ਦੇ ਟੁਪਲਾਂ ਦੁਆਰਾ ਆਉਟਪੁੱਟ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਪਰ ਅੰਤ ਵਿੱਚ ਉਹ ਭੁੱਲ ਜਾਂਦੇ ਹਨ, ਅੰਤਮ ਪੜਾਅ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਵੈਕਟਰ ਦੀ ਇੱਕ ਪਰਿਭਾਸ਼ਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਅਜੇ ਤੱਕ ਕਿਸੇ ਕਿਸਮ ਨਾਲ ਨਹੀਂ ਬੱਝੀ ਹੈ। ਕੀ ਗੱਲ ਹੈ? ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਪ੍ਰੋਗਰਾਮਿੰਗ, ਖਾਸ ਤੌਰ 'ਤੇ ਫੰਕਸ਼ਨਲ, ਬਣਤਰ ਨੂੰ ਵਾਰ-ਵਾਰ ਵਰਣਨ ਕਰਨਾ ਕਾਫ਼ੀ ਆਮ ਹੈ - ਇਸਦੇ ਆਲਸੀ ਮੁਲਾਂਕਣ ਵਾਲਾ ਕੰਪਾਈਲਰ ਸਭ ਕੁਝ ਆਪਣੇ ਆਪ ਸਮਝੇਗਾ ਅਤੇ ਕਰੇਗਾ। ਭਾਸ਼ਾ ਵਿੱਚ ਡਾਟਾ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਕੀ ਲੋੜ ਹੈ ਕੁਸ਼ਲਤਾ: ਇਹ ਸਿਰਫ਼ ਵਰਣਨ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਹੈ ਸੂਚੀ ਵਿੱਚ, i.e. ਦੋ ਤੱਤਾਂ ਦੀ ਬਣਤਰ - ਪਹਿਲਾ ਇੱਕ ਡੇਟਾ ਤੱਤ ਹੈ, ਦੂਜਾ ਉਹੀ ਢਾਂਚਾ ਹੈ ਜਾਂ ਪੂਛ ਲਈ ਇੱਕ ਖਾਲੀ ਥਾਂ ਹੈ (ਪੈਕ (cons) ਲਿਸਪ ਵਿੱਚ). ਪਰ ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਲੋੜ ਹੋਵੇਗੀ ਹਰ ਇਕ ਤੱਤ ਆਪਣੀ ਕਿਸਮ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ ਇੱਕ ਵਾਧੂ 4 ਬਾਈਟ ਖਰਚ ਕਰਦਾ ਹੈ (TL ਵਿੱਚ ਕੇਸ ਵਿੱਚ CRC32)। ਇੱਕ ਐਰੇ ਨੂੰ ਵੀ ਆਸਾਨੀ ਨਾਲ ਵਰਣਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਸਥਿਰ ਆਕਾਰ, ਪਰ ਪਹਿਲਾਂ ਤੋਂ ਅਣਜਾਣ ਲੰਬਾਈ ਦੀ ਲੜੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਅਸੀਂ ਤੋੜ ਦਿੰਦੇ ਹਾਂ।

ਇਸ ਲਈ, ਕਿਉਂਕਿ TL ਇੱਕ ਵੈਕਟਰ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਇਸ ਨੂੰ ਸਾਈਡ 'ਤੇ ਜੋੜਨਾ ਪੈਂਦਾ ਹੈ। ਆਖਰਕਾਰ ਦਸਤਾਵੇਜ਼ ਕਹਿੰਦਾ ਹੈ:

ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਹਮੇਸ਼ਾ ਉਹੀ ਕੰਸਟਰਕਟਰ “ਵੈਕਟਰ” (const 0x1cb5c415 = crc32(“ਵੈਕਟਰ t:Type # [ t ] = ਵੈਕਟਰ t”) ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ ਜੋ ਕਿ t ਦੇ ਵੇਰੀਏਬਲ ਦੇ ਖਾਸ ਮੁੱਲ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੈ।

ਵਿਕਲਪਿਕ ਪੈਰਾਮੀਟਰ ਟੀ ਦਾ ਮੁੱਲ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਵਿੱਚ ਸ਼ਾਮਲ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਨਤੀਜਾ ਕਿਸਮ ਤੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ (ਹਮੇਸ਼ਾ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ)।

ਇੱਕ ਨਜ਼ਦੀਕੀ ਨਜ਼ਰ ਮਾਰੋ: vector {t:Type} # [ t ] = Vector t - ਪਰ ਕਿਤੇ ਨਹੀਂ ਇਹ ਪਰਿਭਾਸ਼ਾ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਨਹੀਂ ਕਹਿੰਦੀ ਕਿ ਪਹਿਲੀ ਸੰਖਿਆ ਵੈਕਟਰ ਦੀ ਲੰਬਾਈ ਦੇ ਬਰਾਬਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ! ਅਤੇ ਇਹ ਕਿਤੇ ਵੀ ਨਹੀਂ ਆਉਂਦਾ. ਇਹ ਇੱਕ ਅਜਿਹਾ ਦਿੱਤਾ ਗਿਆ ਹੈ ਜਿਸਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਅਤੇ ਤੁਹਾਡੇ ਹੱਥਾਂ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਕਿਤੇ ਹੋਰ, ਦਸਤਾਵੇਜ਼ ਵੀ ਇਮਾਨਦਾਰੀ ਨਾਲ ਜ਼ਿਕਰ ਕਰਦੇ ਹਨ ਕਿ ਕਿਸਮ ਅਸਲ ਨਹੀਂ ਹੈ:

ਵੈਕਟਰ ਟੀ ਪੌਲੀਮੋਰਫਿਕ ਸੂਡੋਟਾਇਪ ਇੱਕ "ਕਿਸਮ" ਹੈ ਜਿਸਦਾ ਮੁੱਲ ਕਿਸੇ ਵੀ ਕਿਸਮ ਦੇ ਟੀ ਦੇ ਮੁੱਲਾਂ ਦਾ ਇੱਕ ਕ੍ਰਮ ਹੈ, ਜਾਂ ਤਾਂ ਬਾਕਸਡ ਜਾਂ ਬੇਅਰ।

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

ਤਰੀਕੇ ਨਾਲ, ਨੰਬਰ ਬਾਰੇ. ਆਓ ਤੁਹਾਨੂੰ ਇਹ ਯਾਦ ਦਿਵਾ ਦੇਈਏ # ਇਹ ਇੱਕ ਸਮਾਨਾਰਥੀ ਹੈ nat, ਕੁਦਰਤੀ ਸੰਖਿਆ:

ਕਿਸਮ ਦੇ ਸਮੀਕਰਨ ਹਨ (ਟਾਈਪ-ਐਕਸਪਰ) ਅਤੇ ਅੰਕੀ ਸਮੀਕਰਨ (nat-expr). ਹਾਲਾਂਕਿ, ਉਹਨਾਂ ਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ.

type-expr ::= expr
nat-expr ::= expr

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

ਖੈਰ, ਹਾਂ, ਟੈਂਪਲੇਟ ਕਿਸਮਾਂ (vector<int>, vector<User>) ਕੋਲ ਇੱਕ ਸਾਂਝਾ ਪਛਾਣਕਰਤਾ ਹੈ (#1cb5c415), i.e. ਜੇਕਰ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਕਾਲ ਦੀ ਘੋਸ਼ਣਾ ਕੀਤੀ ਗਈ ਹੈ

users.getUsers#d91a548 id:Vector<InputUser> = Vector<User>;

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

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

ਕੋਡ ਵਿੱਚ ਮੌਜੂਦਾ TL ਲਾਗੂਕਰਨ

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

Templates are not used now. Instead, the same universal constructors (for example, vector {t:Type} [t] = Vector t) are used w

ਪਰ ਆਓ ਵਿਚਾਰ ਕਰੀਏ, ਸੰਪੂਰਨਤਾ ਦੀ ਖ਼ਾਤਰ, ਟਰੇਸ ਕਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ ਬੋਲਣ ਲਈ, ਵਿਚਾਰ ਦੇ ਦੈਂਤ ਦੇ ਵਿਕਾਸ ਨੂੰ.

#define ZHUKOV_BYTES_HACK

#ifdef ZHUKOV_BYTES_HACK

/* dirty hack for Zhukov request */

ਜਾਂ ਇਹ ਸੁੰਦਰ:

    static const char *reserved_words_polymorhic[] = {

      "alpha", "beta", "gamma", "delta", "epsilon", "zeta", "eta", "theta", NULL

      };

ਇਹ ਟੁਕੜਾ ਟੈਂਪਲੇਟਾਂ ਬਾਰੇ ਹੈ ਜਿਵੇਂ ਕਿ:

intHash {alpha:Type} vector<coupleInt<alpha>> = IntHash<alpha>;

ਇਹ ਹੈਸ਼ਮੈਪ ਟੈਂਪਲੇਟ ਕਿਸਮ ਦੀ ਪਰਿਭਾਸ਼ਾ int - ਟਾਈਪ ਜੋੜਿਆਂ ਦੇ ਵੈਕਟਰ ਵਜੋਂ ਹੈ। C++ ਵਿੱਚ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

    template <T> class IntHash {
      vector<pair<int,T>> _map;
    }

ਇਸ ਲਈ, alpha - ਕੀਵਰਡ! ਪਰ ਸਿਰਫ਼ C++ ਵਿੱਚ ਤੁਸੀਂ T ਲਿਖ ਸਕਦੇ ਹੋ, ਪਰ ਤੁਹਾਨੂੰ ਅਲਫ਼ਾ, ਬੀਟਾ ਲਿਖਣਾ ਚਾਹੀਦਾ ਹੈ... ਪਰ 8 ਪੈਰਾਮੀਟਰਾਂ ਤੋਂ ਵੱਧ ਨਹੀਂ, ਇੱਥੇ ਹੀ ਕਲਪਨਾ ਖਤਮ ਹੁੰਦੀ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਸੇਂਟ ਪੀਟਰਸਬਰਗ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਕੁਝ ਸੰਵਾਦ ਹੋਏ ਸਨ:

-- Надо сделать в TL шаблоны
-- Бл... Ну пусть параметры зовут альфа, бета,... Какие там ещё буквы есть... О, тэта!
-- Грамматика? Ну потом напишем

-- Смотрите, какой я синтаксис придумал для шаблонов и вектора!
-- Ты долбанулся, как мы это парсить будем?
-- Да не ссыте, он там один в схеме, захаркодить -- и ок

ਪਰ ਇਹ "ਆਮ ਤੌਰ 'ਤੇ" TL ਦੇ ਪਹਿਲੇ ਪ੍ਰਕਾਸ਼ਿਤ ਲਾਗੂਕਰਨ ਬਾਰੇ ਸੀ। ਆਉ ਟੈਲੀਗ੍ਰਾਮ ਕਲਾਇੰਟਸ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਬਾਰੇ ਵਿਚਾਰ ਕਰਨ ਲਈ ਅੱਗੇ ਵਧੀਏ।

ਵੈਸੀਲੀ ਲਈ ਸ਼ਬਦ:

ਵੈਸੀਲੀ, [09.10.18 17:07] ਸਭ ਤੋਂ ਵੱਧ, ਖੋਤਾ ਗਰਮ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੇ ਐਬਸਟਰੈਕਸ਼ਨਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਬਣਾਇਆ, ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਉੱਤੇ ਇੱਕ ਬੋਲਟ ਮਾਰਿਆ, ਅਤੇ ਕੋਡ ਜਨਰੇਟਰ ਨੂੰ ਬੈਸਾਖੀਆਂ ਨਾਲ ਢੱਕਿਆ।
ਨਤੀਜੇ ਵਜੋਂ, ਪਹਿਲਾਂ ਡੌਕ pilot.jpg ਤੋਂ
ਫਿਰ ਕੋਡ dzhekichan.webp ਤੋਂ

ਬੇਸ਼ੱਕ, ਐਲਗੋਰਿਦਮ ਅਤੇ ਗਣਿਤ ਤੋਂ ਜਾਣੂ ਲੋਕਾਂ ਤੋਂ, ਅਸੀਂ ਉਮੀਦ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਉਹਨਾਂ ਨੇ ਅਹੋ, ਉਲਮੈਨ ਨੂੰ ਪੜ੍ਹਿਆ ਹੈ, ਅਤੇ ਉਹਨਾਂ ਸਾਧਨਾਂ ਤੋਂ ਜਾਣੂ ਹਨ ਜੋ ਆਪਣੇ DSL ਕੰਪਾਈਲਰ ਨੂੰ ਲਿਖਣ ਲਈ ਦਹਾਕਿਆਂ ਤੋਂ ਉਦਯੋਗ ਵਿੱਚ ਡੀ ਫੈਕਟੋ ਸਟੈਂਡਰਡ ਬਣ ਗਏ ਹਨ, ਠੀਕ? ..

ਲੇਖਕ telegram-cli ਵਿਟਾਲੀ ਵਾਲਟਮੈਨ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਸ ਦੀਆਂ (cli) ਸੀਮਾਵਾਂ ਤੋਂ ਬਾਹਰ TLO ਫਾਰਮੈਟ ਦੀ ਮੌਜੂਦਗੀ ਤੋਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਟੀਮ ਦਾ ਇੱਕ ਮੈਂਬਰ - ਹੁਣ TL ਪਾਰਸਿੰਗ ਲਈ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ, ਉਸ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੈ TL ਪਾਰਸਰ? ..

16.12 04:18 ਵੈਸੀਲੀ: ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਕਿਸੇ ਨੇ lex+yacc ਵਿੱਚ ਮੁਹਾਰਤ ਨਹੀਂ ਹਾਸਲ ਕੀਤੀ
16.12 04:18 ਵੈਸੀਲੀ: ਮੈਂ ਇਸਦੀ ਵਿਆਖਿਆ ਨਹੀਂ ਕਰ ਸਕਦਾ
16.12 04:18 ਵੈਸੀਲੀ: ਠੀਕ ਹੈ, ਜਾਂ ਉਹਨਾਂ ਨੂੰ VK ਵਿੱਚ ਲਾਈਨਾਂ ਦੀ ਗਿਣਤੀ ਲਈ ਭੁਗਤਾਨ ਕੀਤਾ ਗਿਆ ਸੀ
16.12 04:19 ਵੈਸੀਲੀ: 3k+ ਲਾਈਨਾਂ ਆਦਿ।<censored> ਇੱਕ ਪਾਰਸਰ ਦੀ ਬਜਾਏ

ਸ਼ਾਇਦ ਇੱਕ ਅਪਵਾਦ? ਆਓ ਦੇਖੀਏ ਕਿਵੇਂ ਕਰਦਾ ਹੈ ਇਹ ਅਧਿਕਾਰਤ ਕਲਾਇੰਟ ਹੈ - ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟਾਪ:

    nametype = re.match(r'([a-zA-Z.0-9_]+)(#[0-9a-f]+)?([^=]*)=s*([a-zA-Z.<>0-9_]+);', line);
    if (not nametype):
      if (not re.match(r'vector#1cb5c415 {t:Type} # [ t ] = Vector t;', line)):
         print('Bad line found: ' + line);

ਪਾਈਥਨ ਵਿੱਚ 1100+ ਲਾਈਨਾਂ, ਕੁਝ ਨਿਯਮਤ ਸਮੀਕਰਨ + ਵਿਸ਼ੇਸ਼ ਕੇਸ ਜਿਵੇਂ ਕਿ ਇੱਕ ਵੈਕਟਰ, ਜੋ ਬੇਸ਼ਕ, ਸਕੀਮ ਵਿੱਚ ਘੋਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ TL ਸੰਟੈਕਸ ਦੇ ਅਨੁਸਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਪਾਰਸ ਕਰਨ ਲਈ ਇਸ ਸੰਟੈਕਸ 'ਤੇ ਭਰੋਸਾ ਕੀਤਾ... ਸਵਾਲ ਪੈਦਾ ਹੁੰਦਾ ਹੈ ਕਿ ਇਹ ਸਭ ਚਮਤਕਾਰ ਕਿਉਂ ਸੀ?иਇਹ ਵਧੇਰੇ ਪੱਧਰੀ ਹੈ ਜੇਕਰ ਕੋਈ ਵੀ ਇਸ ਨੂੰ ਦਸਤਾਵੇਜ਼ਾਂ ਦੇ ਅਨੁਸਾਰ ਪਾਰਸ ਨਹੀਂ ਕਰਨ ਜਾ ਰਿਹਾ ਹੈ?!

ਤਰੀਕੇ ਨਾਲ... ਯਾਦ ਹੈ ਕਿ ਅਸੀਂ CRC32 ਜਾਂਚ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਸੀ? ਇਸ ਲਈ, ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟੌਪ ਕੋਡ ਜਨਰੇਟਰ ਵਿੱਚ ਉਹਨਾਂ ਕਿਸਮਾਂ ਲਈ ਅਪਵਾਦਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਹੈ ਜਿਸ ਵਿੱਚ CRC32 ਦੀ ਗਣਨਾ ਕੀਤੀ ਗਈ ਹੈ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਚਿੱਤਰ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਇੱਕ ਦੇ ਨਾਲ!

ਵੈਸੀਲੀ, [18.12/22 49:XNUMX] ਅਤੇ ਇੱਥੇ ਮੈਂ ਇਸ ਬਾਰੇ ਸੋਚਾਂਗਾ ਕਿ ਕੀ ਅਜਿਹੇ TL ਦੀ ਲੋੜ ਹੈ
ਜੇ ਮੈਂ ਵਿਕਲਪਿਕ ਲਾਗੂਕਰਨਾਂ ਨਾਲ ਗੜਬੜ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਤਾਂ ਮੈਂ ਲਾਈਨ ਬ੍ਰੇਕ ਸ਼ਾਮਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਾਂਗਾ, ਅੱਧੇ ਪਾਰਸਰ ਮਲਟੀ-ਲਾਈਨ ਪਰਿਭਾਸ਼ਾਵਾਂ 'ਤੇ ਟੁੱਟ ਜਾਣਗੇ।
tdesktop, ਹਾਲਾਂਕਿ, ਵੀ

ਵਨ-ਲਾਈਨਰ ਬਾਰੇ ਗੱਲ ਯਾਦ ਰੱਖੋ, ਅਸੀਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ ਇਸ 'ਤੇ ਵਾਪਸ ਆਵਾਂਗੇ।

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

ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਭਿਆਸ ਵਿੱਚ ਹੋਰ ਕਿਹੜੇ ਮੁੱਦੇ ਉਠਾਉਂਦੀ ਹੈ? ਉਦਾਹਰਨ ਲਈ, ਉਹਨਾਂ ਨੇ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਕੀਤੀਆਂ, ਬੇਸ਼ਕ, ਬਿੱਟ ਖੇਤਰਾਂ ਅਤੇ ਸ਼ਰਤੀਆ ਖੇਤਰਾਂ ਦੇ ਨਾਲ:

ਵੈਸੀਲੀ: flags.0? true
ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਫੀਲਡ ਮੌਜੂਦ ਹੈ ਅਤੇ ਜੇਕਰ ਫਲੈਗ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ ਤਾਂ ਸਹੀ ਹੈ

ਵੈਸੀਲੀ: flags.1? int
ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਖੇਤਰ ਮੌਜੂਦ ਹੈ ਅਤੇ ਡੀਸੀਰੀਅਲਾਈਜ਼ ਕਰਨ ਦੀ ਲੋੜ ਹੈ

ਵੈਸੀਲੀ: ਗਧੇ, ਤੁਸੀਂ ਕੀ ਕਰ ਰਹੇ ਹੋ ਇਸ ਬਾਰੇ ਚਿੰਤਾ ਨਾ ਕਰੋ!
ਵੈਸੀਲੀ: ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਕਿਤੇ ਇੱਕ ਜ਼ਿਕਰ ਹੈ ਕਿ ਸੱਚ ਇੱਕ ਬੇਰ ਜ਼ੀਰੋ-ਲੰਬਾਈ ਕਿਸਮ ਹੈ, ਪਰ ਉਹਨਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਕੁਝ ਵੀ ਇਕੱਠਾ ਕਰਨਾ ਅਸੰਭਵ ਹੈ
ਵੈਸੀਲੀ: ਓਪਨ ਸੋਰਸ ਸਥਾਪਨ ਵਿੱਚ ਵੀ ਅਜਿਹਾ ਨਹੀਂ ਹੈ, ਪਰ ਇੱਥੇ ਬਹੁਤ ਸਾਰੀਆਂ ਬੈਸਾਖੀਆਂ ਅਤੇ ਸਹਾਇਤਾ ਹਨ

ਟੈਲੀਥੌਨ ਬਾਰੇ ਕੀ? MTProto ਦੇ ਵਿਸ਼ੇ ਨੂੰ ਅੱਗੇ ਦੇਖਦੇ ਹੋਏ, ਇੱਕ ਉਦਾਹਰਨ - ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਅਜਿਹੇ ਟੁਕੜੇ ਹਨ, ਪਰ ਚਿੰਨ੍ਹ % ਇਸਦਾ ਵਰਣਨ ਸਿਰਫ "ਕਿਸੇ ਦਿੱਤੇ ਬੇਅਰ-ਟਾਈਪ ਦੇ ਅਨੁਸਾਰੀ" ਵਜੋਂ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਜਾਂ ਤਾਂ ਕੋਈ ਗਲਤੀ ਹੈ ਜਾਂ ਕੁਝ ਗੈਰ-ਦਸਤਾਵੇਜ਼ਿਤ ਹੈ:

ਵੈਸੀਲੀ, [22.06.18 18:38] ਇੱਕ ਥਾਂ:

msg_container#73f1f8dc messages:vector message = MessageContainer;

ਇੱਕ ਵੱਖਰੇ ਰੂਪ ਵਿੱਚ:

msg_container#73f1f8dc messages:vector<%Message> = MessageContainer;

ਅਤੇ ਇਹ ਦੋ ਵੱਡੇ ਅੰਤਰ ਹਨ, ਅਸਲ ਜੀਵਨ ਵਿੱਚ ਕਿਸੇ ਕਿਸਮ ਦਾ ਨੰਗੇ ਵੈਕਟਰ ਆਉਂਦਾ ਹੈ

ਮੈਂ ਕੋਈ ਬੇਅਰ ਵੈਕਟਰ ਪਰਿਭਾਸ਼ਾ ਨਹੀਂ ਦੇਖੀ ਹੈ ਅਤੇ ਮੈਂ ਇੱਕ ਵਿੱਚ ਨਹੀਂ ਆਇਆ ਹਾਂ

ਵਿਸ਼ਲੇਸ਼ਣ ਟੈਲੀਥੌਨ ਵਿੱਚ ਹੱਥ ਨਾਲ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ

ਉਸਦੇ ਚਿੱਤਰ ਵਿੱਚ ਪਰਿਭਾਸ਼ਾ ਦੀ ਟਿੱਪਣੀ ਕੀਤੀ ਗਈ ਹੈ msg_container

ਦੁਬਾਰਾ ਫਿਰ, ਸਵਾਲ % ਬਾਰੇ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਵਰਣਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ.

Vadim Goncharov, [22.06.18 19:22] ਅਤੇ tdesktop ਵਿੱਚ?

ਵੈਸੀਲੀ, [22.06.18 19:23] ਪਰ ਨਿਯਮਤ ਇੰਜਣਾਂ 'ਤੇ ਉਨ੍ਹਾਂ ਦੇ TL ਪਾਰਸਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇਸ ਨੂੰ ਵੀ ਨਹੀਂ ਖਾਣਗੇ।

// parsed manually

TL ਇੱਕ ਸੁੰਦਰ ਐਬਸਟਰੈਕਸ਼ਨ ਹੈ, ਕੋਈ ਵੀ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲਾਗੂ ਨਹੀਂ ਕਰਦਾ

ਅਤੇ % ਸਕੀਮ ਦੇ ਉਹਨਾਂ ਦੇ ਸੰਸਕਰਣ ਵਿੱਚ ਨਹੀਂ ਹੈ

ਪਰ ਇੱਥੇ ਦਸਤਾਵੇਜ਼ ਆਪਣੇ ਆਪ ਦੇ ਉਲਟ ਹੈ, ਇਸ ਲਈ idk

ਇਹ ਵਿਆਕਰਣ ਵਿੱਚ ਪਾਇਆ ਗਿਆ ਸੀ, ਉਹ ਬਸ ਅਰਥ-ਸ਼ਾਸਤਰ ਦਾ ਵਰਣਨ ਕਰਨਾ ਭੁੱਲ ਸਕਦੇ ਸਨ

ਤੁਸੀਂ TL 'ਤੇ ਦਸਤਾਵੇਜ਼ ਦੇਖਿਆ, ਤੁਸੀਂ ਅੱਧੇ ਲੀਟਰ ਤੋਂ ਬਿਨਾਂ ਇਸਦਾ ਪਤਾ ਨਹੀਂ ਲਗਾ ਸਕਦੇ

“ਠੀਕ ਹੈ, ਚਲੋ ਕਹੋ,” ਇਕ ਹੋਰ ਪਾਠਕ ਕਹੇਗਾ, “ਤੁਸੀਂ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਆਲੋਚਨਾ ਕਰਦੇ ਹੋ, ਇਸ ਲਈ ਮੈਨੂੰ ਦੱਸੋ ਕਿ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।”

ਵੈਸੀਲੀ ਜਵਾਬ ਦਿੰਦਾ ਹੈ: “ਜਿੱਥੋਂ ਤੱਕ ਪਾਰਸਰ ਲਈ, ਮੈਨੂੰ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਪਸੰਦ ਹਨ

    args: /* empty */ { $$ = NULL; }
        | args arg { $$ = g_list_append( $1, $2 ); }
        ;

    arg: LC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | LC_ID ':' condition '?' type-term { $$ = tl_arg_new_cond( $1, $5, $3 ); free($3); }
            | UC_ID ':' type-term { $$ = tl_arg_new( $1, $3 ); }
            | type-term { $$ = tl_arg_new( "", $1 ); }
            | '[' LC_ID ']' { $$ = tl_arg_new_mult( "", tl_type_new( $2, TYPE_MOD_NONE ) ); }
            ;

ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਸ ਨੂੰ ਬਿਹਤਰ ਪਸੰਦ ਹੈ

struct tree *parse_args4 (void) {
  PARSE_INIT (type_args4);
  struct parse so = save_parse ();
  PARSE_TRY (parse_optional_arg_def);
  if (S) {
    tree_add_child (T, S);
  } else {
    load_parse (so);
  }
  if (LEX_CHAR ('!')) {
    PARSE_ADD (type_exclam);
    EXPECT ("!");
  }
  PARSE_TRY_PES (parse_type_term);
  PARSE_OK;
}

ਜ

        # Regex to match the whole line
        match = re.match(r'''
            ^                  # We want to match from the beginning to the end
            ([w.]+)           # The .tl object can contain alpha_name or namespace.alpha_name
            (?:
                #             # After the name, comes the ID of the object
                ([0-9a-f]+)    # The constructor ID is in hexadecimal form
            )?                 # If no constructor ID was given, CRC32 the 'tl' to determine it

            (?:s              # After that, we want to match its arguments (name:type)
                {?             # For handling the start of the '{X:Type}' case
                w+            # The argument name will always be an alpha-only name
                :              # Then comes the separator between name:type
                [wd<>#.?!]+  # The type is slightly more complex, since it's alphanumeric and it can
                               # also have Vector<type>, flags:# and flags.0?default, plus :!X as type
                }?             # For handling the end of the '{X:Type}' case
            )*                 # Match 0 or more arguments
            s                 # Leave a space between the arguments and the equal
            =
            s                 # Leave another space between the equal and the result
            ([wd<>#.?]+)     # The result can again be as complex as any argument type
            ;$                 # Finally, the line should always end with ;
            ''', tl, re.IGNORECASE | re.VERBOSE)

ਇਹ ਪੂਰਾ ਲੈਕਸਰ ਹੈ:

    ---functions---         return FUNCTIONS;
    ---types---             return TYPES;
    [a-z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return LC_ID;
    [A-Z][a-zA-Z0-9_]*      yylval.string = strdup(yytext); return UC_ID;
    [0-9]+                  yylval.number = atoi(yytext); return NUM;
    #[0-9a-fA-F]{1,8}       yylval.number = strtol(yytext+1, NULL, 16); return ID_HASH;

    n                      /* skip new line */
    [ t]+                  /* skip spaces */
    //.*$                 /* skip comments */
    /*.**/              /* skip comments */
    .                       return (int)yytext[0];

ਉਹ. ਸਧਾਰਨ ਇਸ ਨੂੰ ਹਲਕੇ ਢੰਗ ਨਾਲ ਪਾ ਰਿਹਾ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਨਤੀਜੇ ਵਜੋਂ, TL ਦੇ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਗਏ ਸਬਸੈੱਟ ਲਈ ਪਾਰਸਰ ਅਤੇ ਕੋਡ ਜਨਰੇਟਰ ਵਿਆਕਰਣ ਦੀਆਂ ਲਗਭਗ 100 ਲਾਈਨਾਂ ਅਤੇ ਜਨਰੇਟਰ ਦੀਆਂ ~300 ਲਾਈਨਾਂ ਵਿੱਚ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ (ਸਾਰੀਆਂ ਦੀ ਗਿਣਤੀ ਕਰਦੇ ਹੋਏ printਦਾ ਤਿਆਰ ਕੀਤਾ ਕੋਡ), ਜਿਸ ਵਿੱਚ ਹਰੇਕ ਕਲਾਸ ਵਿੱਚ ਸਵੈ-ਨਿਰੀਖਣ ਲਈ ਟਾਈਪ ਜਾਣਕਾਰੀ ਬੰਸ ਸ਼ਾਮਲ ਹੈ। ਹਰੇਕ ਪੌਲੀਮੋਰਫਿਕ ਕਿਸਮ ਇੱਕ ਖਾਲੀ ਐਬਸਟਰੈਕਟ ਬੇਸ ਕਲਾਸ ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਕੰਸਟਰਕਟਰ ਇਸ ਤੋਂ ਵਿਰਾਸਤ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ ਅਤੇ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਅਤੇ ਡੀਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਲਈ ਢੰਗ ਰੱਖਦੇ ਹਨ।

ਟਾਈਪ ਭਾਸ਼ਾ ਵਿੱਚ ਕਿਸਮਾਂ ਦੀ ਘਾਟ

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

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਪਾਬੰਦੀਆਂ. ਇੱਥੇ ਅਸੀਂ ਫਾਈਲਾਂ ਨੂੰ ਅਪਲੋਡ ਕਰਨ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਵੇਖਦੇ ਹਾਂ:

ਫਾਈਲ ਦੀ ਬਾਈਨਰੀ ਸਮੱਗਰੀ ਨੂੰ ਫਿਰ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਸਾਰੇ ਹਿੱਸਿਆਂ ਦਾ ਆਕਾਰ ਇੱਕੋ ਜਿਹਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ( ਭਾਗ_ਆਕਾਰ ) ਅਤੇ ਹੇਠ ਲਿਖੀਆਂ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ:

• part_size % 1024 = 0 (1KB ਨਾਲ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ)
• 524288 % part_size = 0 (512KB ਭਾਗ_ਆਕਾਰ ਦੁਆਰਾ ਬਰਾਬਰ ਵੰਡਣ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ)

ਆਖਰੀ ਭਾਗ ਨੂੰ ਇਹਨਾਂ ਸ਼ਰਤਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਬਸ਼ਰਤੇ ਇਸਦਾ ਆਕਾਰ part_size ਤੋਂ ਘੱਟ ਹੋਵੇ।

ਹਰੇਕ ਹਿੱਸੇ ਦਾ ਇੱਕ ਕ੍ਰਮ ਨੰਬਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, file_part, 0 ਤੋਂ 2,999 ਤੱਕ ਦੇ ਮੁੱਲ ਦੇ ਨਾਲ।

ਫਾਈਲ ਨੂੰ ਵੰਡਣ ਤੋਂ ਬਾਅਦ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਸਰਵਰ ਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨ ਲਈ ਇੱਕ ਢੰਗ ਚੁਣਨ ਦੀ ਲੋੜ ਹੈ। ਵਰਤੋ upload.saveBigFilePart ਜੇਕਰ ਫਾਈਲ ਦਾ ਪੂਰਾ ਆਕਾਰ 10 MB ਤੋਂ ਵੱਧ ਹੈ ਅਤੇ upload.saveFilePart ਛੋਟੀਆਂ ਫਾਈਲਾਂ ਲਈ.
[...] ਨਿਮਨਲਿਖਤ ਡੇਟਾ ਇਨਪੁਟ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਵਾਪਸ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ:

• FILE_PARTS_INVALID — ਭਾਗਾਂ ਦੀ ਅਵੈਧ ਸੰਖਿਆ। ਮੁੱਲ ਵਿਚਕਾਰ ਨਹੀਂ ਹੈ 1..3000

ਕੀ ਇਸ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਚਿੱਤਰ ਵਿੱਚ ਹੈ? ਕੀ ਇਹ TL ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਿਸੇ ਤਰ੍ਹਾਂ ਪ੍ਰਗਟਾਵੇਯੋਗ ਹੈ? ਨੰ. ਪਰ ਮੈਨੂੰ ਮਾਫ਼ ਕਰਨਾ, ਇੱਥੋਂ ਤੱਕ ਕਿ ਦਾਦਾ ਜੀ ਦਾ ਟਰਬੋ ਪਾਸਕਲ ਵੀ ਨਿਰਧਾਰਤ ਕਿਸਮਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਦੇ ਯੋਗ ਸੀ ਸੀਮਾਵਾਂ. ਅਤੇ ਉਹ ਇੱਕ ਹੋਰ ਚੀਜ਼ ਜਾਣਦਾ ਸੀ, ਜਿਸਨੂੰ ਹੁਣ ਵਧੇਰੇ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ enum - ਇੱਕ ਕਿਸਮ ਜਿਸ ਵਿੱਚ ਮੁੱਲਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ (ਛੋਟੀ) ਸੰਖਿਆ ਦੀ ਗਿਣਤੀ ਹੁੰਦੀ ਹੈ। C - numeric ਵਰਗੀਆਂ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ, ਨੋਟ ਕਰੋ ਕਿ ਹੁਣ ਤੱਕ ਅਸੀਂ ਸਿਰਫ ਕਿਸਮਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ ਹੈ ਨੰਬਰ. ਪਰ ਇੱਥੇ ਐਰੇ, ਸਤਰ ਵੀ ਹਨ... ਉਦਾਹਰਨ ਲਈ, ਇਹ ਵਰਣਨ ਕਰਨਾ ਚੰਗਾ ਹੋਵੇਗਾ ਕਿ ਇਸ ਸਤਰ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਫ਼ੋਨ ਨੰਬਰ ਹੋ ਸਕਦਾ ਹੈ, ਠੀਕ ਹੈ?

ਇਸ ਵਿੱਚੋਂ ਕੋਈ ਵੀ TL ਵਿੱਚ ਨਹੀਂ ਹੈ। ਪਰ ਉੱਥੇ ਹੈ, ਉਦਾਹਰਨ ਲਈ, JSON ਸਕੀਮਾ ਵਿੱਚ. ਅਤੇ ਜੇਕਰ ਕੋਈ ਹੋਰ 512 KB ਦੀ ਵਿਭਾਜਕਤਾ ਬਾਰੇ ਬਹਿਸ ਕਰ ਸਕਦਾ ਹੈ, ਕਿ ਇਸ ਨੂੰ ਅਜੇ ਵੀ ਕੋਡ ਵਿੱਚ ਚੈੱਕ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਗਾਹਕ ਨੂੰ ਸਿਰਫ਼ ਮੈਂ ਨਹੀਂ ਕਰ ਸਕਿਆ ਸੀਮਾ ਦੇ ਬਾਹਰ ਇੱਕ ਨੰਬਰ ਭੇਜੋ 1..3000 (ਅਤੇ ਅਨੁਸਾਰੀ ਗਲਤੀ ਪੈਦਾ ਨਹੀਂ ਹੋ ਸਕਦੀ ਸੀ) ਇਹ ਸੰਭਵ ਹੋ ਸਕਦਾ ਸੀ, ਠੀਕ? ..

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

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

-channelFull#76af5481 flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;
+channelFull#1c87a71a flags:# can_view_participants:flags.3?true can_set_username:flags.6?true can_set_stickers:flags.7?true hidden_prehistory:flags.10?true can_view_stats:flags.12?true id:int about:string participants_count:flags.0?int admins_count:flags.1?int kicked_count:flags.2?int banned_count:flags.2?int online_count:flags.13?int read_inbox_max_id:int read_outbox_max_id:int unread_count:int chat_photo:Photo notify_settings:PeerNotifySettings exported_invite:ExportedChatInvite bot_info:Vector<BotInfo> migrated_from_chat_id:flags.4?int migrated_from_max_id:flags.4?int pinned_msg_id:flags.5?int stickerset:flags.8?StickerSet available_min_id:flags.9?int = ChatFull;

ਜ

-message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;
+message#44f9b43d flags:# out:flags.1?true mentioned:flags.4?true media_unread:flags.5?true silent:flags.13?true post:flags.14?true from_scheduled:flags.18?true id:int from_id:flags.8?int to_id:Peer fwd_from:flags.2?MessageFwdHeader via_bot_id:flags.11?int reply_to_msg_id:flags.3?int date:int message:string media:flags.9?MessageMedia reply_markup:flags.6?ReplyMarkup entities:flags.7?Vector<MessageEntity> views:flags.10?int edit_date:flags.15?int post_author:flags.16?string grouped_id:flags.17?long = Message;

ਇਹ ਹਰ ਕਿਸੇ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਪਰ GitHub, ਉਦਾਹਰਨ ਲਈ, ਅਜਿਹੀਆਂ ਲੰਬੀਆਂ ਲਾਈਨਾਂ ਦੇ ਅੰਦਰ ਤਬਦੀਲੀਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ. ਗੇਮ “10 ਅੰਤਰ ਲੱਭੋ”, ਅਤੇ ਜੋ ਦਿਮਾਗ ਤੁਰੰਤ ਵੇਖਦਾ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ ਦੋਵਾਂ ਉਦਾਹਰਣਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਅੰਤ ਇਕੋ ਜਿਹੇ ਹਨ, ਤੁਹਾਨੂੰ ਮੱਧ ਵਿਚ ਕਿਤੇ ਪੜ੍ਹਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ... ਮੇਰੀ ਰਾਏ ਵਿਚ, ਇਹ ਸਿਰਫ ਸਿਧਾਂਤ ਵਿਚ ਨਹੀਂ ਹੈ, ਪਰ ਪੂਰੀ ਨਜ਼ਰ ਨਾਲ ਗੰਦਾ ਅਤੇ ਢਿੱਲਾ.

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

storage.fileUnknown#aa963b05 = storage.FileType;
storage.filePartial#40bc6f52 = storage.FileType;
storage.fileJpeg#7efe0e = storage.FileType;
storage.fileGif#cae1aadf = storage.FileType;
storage.filePng#a4f63c0 = storage.FileType;
storage.filePdf#ae1e508d = storage.FileType;
storage.fileMp3#528a0677 = storage.FileType;
storage.fileMov#4b09ebbc = storage.FileType;
storage.fileMp4#b3cea0e4 = storage.FileType;
storage.fileWebp#1081464c = storage.FileType;

ਪਰ ਹੁਣ ਕਲਪਨਾ ਕਰੋ, ਜੇਕਰ ਤੁਹਾਡੇ ਢਾਂਚੇ ਵਿੱਚ 5 ਵਿਕਲਪਿਕ ਖੇਤਰ ਹਨ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਾਰੇ ਸੰਭਵ ਵਿਕਲਪਾਂ ਲਈ 32 ਕਿਸਮਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਸੰਯੁਕਤ ਧਮਾਕਾ. ਇਸ ਤਰ੍ਹਾਂ, ਟੀਐਲ ਥਿਊਰੀ ਦੀ ਕ੍ਰਿਸਟਲ ਸ਼ੁੱਧਤਾ ਇੱਕ ਵਾਰ ਫਿਰ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਦੀ ਕਠੋਰ ਅਸਲੀਅਤ ਦੇ ਕਾਸਟ-ਆਇਰਨ ਗਧੇ ਦੇ ਵਿਰੁੱਧ ਚਕਨਾਚੂਰ ਹੋ ਗਈ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੁਝ ਥਾਵਾਂ 'ਤੇ ਇਹ ਲੋਕ ਖੁਦ ਆਪਣੀ ਟਾਈਪੋਲੋਜੀ ਦੀ ਉਲੰਘਣਾ ਕਰਦੇ ਹਨ. ਉਦਾਹਰਨ ਲਈ, MTProto (ਅਗਲਾ ਅਧਿਆਇ) ਵਿੱਚ ਜਵਾਬ ਨੂੰ Gzip ਦੁਆਰਾ ਸੰਕੁਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਸਭ ਕੁਝ ਠੀਕ ਹੈ - ਸਿਵਾਏ ਕਿ ਲੇਅਰਾਂ ਅਤੇ ਸਰਕਟ ਦੀ ਉਲੰਘਣਾ ਕੀਤੀ ਗਈ ਹੈ. ਇੱਕ ਵਾਰ ਫਿਰ, ਇਹ ਖੁਦ RpcResult ਨਹੀਂ ਸੀ ਜੋ ਵੱਢਿਆ ਗਿਆ ਸੀ, ਪਰ ਇਸਦੀ ਸਮੱਗਰੀ। ਖੈਰ, ਅਜਿਹਾ ਕਿਉਂ ਕੀਤਾ?... ਮੈਨੂੰ ਇੱਕ ਬੈਸਾਖੀ ਵਿੱਚ ਕੱਟਣਾ ਪਿਆ ਤਾਂ ਕਿ ਕੰਪਰੈਸ਼ਨ ਕਿਤੇ ਵੀ ਕੰਮ ਕਰੇ।

ਜਾਂ ਇੱਕ ਹੋਰ ਉਦਾਹਰਨ, ਸਾਨੂੰ ਇੱਕ ਵਾਰ ਇੱਕ ਗਲਤੀ ਦਾ ਪਤਾ ਲੱਗਾ - ਇਹ ਭੇਜਿਆ ਗਿਆ ਸੀ InputPeerUser ਦੀ ਬਜਾਏ InputUser. ਜਾਂ ਉਲਟ. ਪਰ ਇਹ ਕੰਮ ਕੀਤਾ! ਭਾਵ, ਸਰਵਰ ਨੇ ਕਿਸਮ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕੀਤੀ। ਇਹ ਕਿਵੇਂ ਹੋ ਸਕਦਾ ਹੈ? ਜਵਾਬ ਸਾਨੂੰ ਟੈਲੀਗ੍ਰਾਮ-ਕਲੀ ਤੋਂ ਕੋਡ ਦੇ ਟੁਕੜਿਆਂ ਦੁਆਰਾ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ:

  if (tgl_get_peer_type (E->id) != TGL_PEER_CHANNEL || (C && (C->flags & TGLCHF_MEGAGROUP))) {
    out_int (CODE_messages_get_history);
    out_peer_id (TLS, E->id);
  } else {    
    out_int (CODE_channels_get_important_history);

    out_int (CODE_input_channel);
    out_int (tgl_get_peer_id (E->id));
    out_long (E->id.access_hash);
  }
  out_int (E->max_id);
  out_int (E->offset);
  out_int (E->limit);
  out_int (0);
  out_int (0);

ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਹੱਥੀਂ, ਕੋਡ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ! ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਰਵਰ ਨੂੰ ਇਸੇ ਤਰ੍ਹਾਂ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੋਵੇ?... ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਹ ਕੰਮ ਕਰੇਗਾ ਜੇਕਰ ਇੱਕ ਵਾਰ ਕੀਤਾ ਜਾਵੇ, ਪਰ ਬਾਅਦ ਵਿੱਚ ਅੱਪਡੇਟ ਦੇ ਦੌਰਾਨ ਇਸਨੂੰ ਕਿਵੇਂ ਸਮਰਥਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਕੀ ਇਸ ਲਈ ਯੋਜਨਾ ਦੀ ਕਾਢ ਕੱਢੀ ਗਈ ਸੀ? ਅਤੇ ਇੱਥੇ ਅਸੀਂ ਅਗਲੇ ਸਵਾਲ ਵੱਲ ਵਧਦੇ ਹਾਂ.

ਸੰਸਕਰਣ. ਪਰਤਾਂ

ਯੋਜਨਾਬੱਧ ਸੰਸਕਰਣਾਂ ਨੂੰ ਪਰਤਾਂ ਕਿਉਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਕਾਸ਼ਿਤ ਯੋਜਨਾ ਵਿਗਿਆਨ ਦੇ ਇਤਿਹਾਸ ਦੇ ਆਧਾਰ 'ਤੇ ਹੀ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਜ਼ਾਹਰਾ ਤੌਰ 'ਤੇ, ਪਹਿਲਾਂ ਲੇਖਕਾਂ ਨੇ ਸੋਚਿਆ ਕਿ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਨੂੰ ਨਾ ਬਦਲੀ ਗਈ ਸਕੀਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਜਿੱਥੇ ਲੋੜ ਹੋਵੇ, ਖਾਸ ਬੇਨਤੀਆਂ ਲਈ, ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਉਹ ਇੱਕ ਵੱਖਰੇ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੀਤੇ ਜਾ ਰਹੇ ਸਨ। ਸਿਧਾਂਤ ਵਿੱਚ, ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਵੀ - ਅਤੇ ਨਵਾਂ ਹੋਵੇਗਾ, ਜਿਵੇਂ ਕਿ ਇਹ ਸਨ, "ਮਿਸ਼ਰਤ", ਪੁਰਾਣੇ ਦੇ ਸਿਖਰ 'ਤੇ ਪਰਤਿਆ ਹੋਇਆ। ਪਰ ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਗਿਆ ਸੀ. ਇਹ ਸੱਚ ਹੈ ਕਿ ਮੈਂ ਇਸ ਨੂੰ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਦੇਖਣ ਦੇ ਯੋਗ ਨਹੀਂ ਸੀ - ਇਹ ਮਜ਼ਾਕੀਆ ਹੈ, ਪਰ ਬੇਸ ਲੇਅਰ ਦਾ ਚਿੱਤਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ। ਪਰਤਾਂ 2 ਨਾਲ ਸ਼ੁਰੂ ਹੋਈਆਂ। ਦਸਤਾਵੇਜ਼ ਸਾਨੂੰ ਇੱਕ ਵਿਸ਼ੇਸ਼ TL ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਰੇ ਦੱਸਦਾ ਹੈ:

ਜੇਕਰ ਇੱਕ ਕਲਾਇੰਟ ਲੇਅਰ 2 ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਹੇਠਾਂ ਦਿੱਤੇ ਕੰਸਟਰਕਟਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ:

invokeWithLayer2#289dd1f6 {X:Type} query:!X = X;

ਅਭਿਆਸ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹਰੇਕ API ਕਾਲ ਤੋਂ ਪਹਿਲਾਂ, ਮੁੱਲ ਦੇ ਨਾਲ ਇੱਕ int 0x289dd1f6 ਵਿਧੀ ਨੰਬਰ ਤੋਂ ਪਹਿਲਾਂ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਆਮ ਲੱਗਦੀ ਹੈ। ਪਰ ਅੱਗੇ ਕੀ ਹੋਇਆ? ਫਿਰ ਪ੍ਰਗਟ ਹੋਇਆ

invokeWithLayer3#b7475268 query:!X = X;

ਇਸ ਲਈ ਅੱਗੇ ਕੀ ਹੈ? ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ,

invokeWithLayer4#dea0d430 query:!X = X;

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

invokeWithLayer5#417a57ae query:!X = X;

ਪਰ ਜ਼ਾਹਰ ਹੈ ਕਿ ਥੋੜ੍ਹੇ ਸਮੇਂ ਬਾਅਦ ਇਹ ਕਿਸੇ ਕਿਸਮ ਦਾ ਬਕਵਾਸ ਬਣ ਜਾਵੇਗਾ। ਅਤੇ ਹੱਲ ਆਇਆ:

ਅੱਪਡੇਟ: ਲੇਅਰ 9 ਨਾਲ ਸ਼ੁਰੂ ਹੋ ਰਿਹਾ ਹੈ, ਸਹਾਇਕ ਢੰਗ invokeWithLayerN ਨਾਲ ਹੀ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ initConnection

ਹੂਰੇ! 9 ਸੰਸਕਰਣਾਂ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ ਅੰਤ ਵਿੱਚ 80 ਦੇ ਦਹਾਕੇ ਵਿੱਚ ਇੰਟਰਨੈਟ ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਕੀ ਕੀਤਾ ਗਿਆ ਸੀ - ਕੁਨੈਕਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਇੱਕ ਵਾਰ ਸੰਸਕਰਣ 'ਤੇ ਸਹਿਮਤ ਹੋਏ!

ਤਾਂ ਅੱਗੇ ਕੀ ਹੈ? ..

invokeWithLayer10#39620c41 query:!X = X;
...
invokeWithLayer18#1c900537 query:!X = X;

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

ਬਿਲਕੁਲ?..

ਵੈਸੀਲੀ, [16.07.18 14:01] ਸ਼ੁੱਕਰਵਾਰ ਨੂੰ ਵੀ ਮੈਂ ਸੋਚਿਆ:
ਟੈਲੀਸਰਵਰ ਬਿਨਾਂ ਕਿਸੇ ਬੇਨਤੀ ਦੇ ਇਵੈਂਟਸ ਭੇਜਦਾ ਹੈ। ਬੇਨਤੀਆਂ ਨੂੰ InvokeWithLayer ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਰਵਰ ਅੱਪਡੇਟਾਂ ਨੂੰ ਸਮੇਟਦਾ ਨਹੀਂ ਹੈ; ਜਵਾਬਾਂ ਅਤੇ ਅੱਪਡੇਟਾਂ ਨੂੰ ਸਮੇਟਣ ਲਈ ਕੋਈ ਢਾਂਚਾ ਨਹੀਂ ਹੈ।

ਉਹ. ਕਲਾਇੰਟ ਉਹ ਪਰਤ ਨਹੀਂ ਦੱਸ ਸਕਦਾ ਜਿਸ ਵਿੱਚ ਉਹ ਅੱਪਡੇਟ ਚਾਹੁੰਦਾ ਹੈ

Vadim Goncharov, [16.07.18 14:02] ਕੀ InvokeWithLayer ਸਿਧਾਂਤ ਵਿੱਚ ਇੱਕ ਬੈਸਾਖੀ ਨਹੀਂ ਹੈ?

ਵੈਸੀਲੀ, [16.07.18 14:02] ਇਹ ਇੱਕੋ ਇੱਕ ਤਰੀਕਾ ਹੈ

Vadim Goncharov, [16.07.18 14:02] ਜਿਸਦਾ ਮਤਲਬ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਪਰਤ 'ਤੇ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਤਰੀਕੇ ਨਾਲ, ਇਹ ਇਸ ਗੱਲ ਦੀ ਪਾਲਣਾ ਕਰਦਾ ਹੈ ਕਿ ਕਲਾਇੰਟ ਡਾਊਨਗ੍ਰੇਡ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ

ਅੱਪਡੇਟ, i.e. ਕਿਸਮ Updates ਸਕੀਮ ਵਿੱਚ, ਇਹ ਉਹ ਹੈ ਜੋ ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਇੱਕ API ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਵਿੱਚ ਨਹੀਂ, ਸਗੋਂ ਸੁਤੰਤਰ ਤੌਰ 'ਤੇ ਭੇਜਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਘਟਨਾ ਵਾਪਰਦੀ ਹੈ। ਇਹ ਇੱਕ ਗੁੰਝਲਦਾਰ ਵਿਸ਼ਾ ਹੈ ਜਿਸ ਬਾਰੇ ਕਿਸੇ ਹੋਰ ਪੋਸਟ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ, ਪਰ ਹੁਣ ਲਈ ਇਹ ਜਾਣਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਸਰਵਰ ਅੱਪਡੇਟਾਂ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਭਾਵੇਂ ਕਲਾਇੰਟ ਆਫ਼ਲਾਈਨ ਹੋਵੇ।

ਇਸ ਤਰ੍ਹਾਂ, ਜੇ ਤੁਸੀਂ ਲਪੇਟਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦੇ ਹੋ ਹਰ ਇਕ ਪੈਕੇਜ ਇਸਦੇ ਸੰਸਕਰਣ ਨੂੰ ਦਰਸਾਉਣ ਲਈ, ਇਹ ਤਰਕ ਨਾਲ ਹੇਠ ਲਿਖੀਆਂ ਸੰਭਵ ਸਮੱਸਿਆਵਾਂ ਵੱਲ ਖੜਦਾ ਹੈ:

• ਸਰਵਰ ਕਲਾਇੰਟ ਨੂੰ ਅੱਪਡੇਟ ਭੇਜਦਾ ਹੈ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕਲਾਇੰਟ ਇਹ ਦੱਸੇ ਕਿ ਇਹ ਕਿਸ ਸੰਸਕਰਣ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ
• ਕਲਾਇੰਟ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੈਨੂੰ ਕੀ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ?
• ਕੌਣ ਗਾਰੰਟੀਕਿ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਲੇਅਰ ਨੰਬਰ ਬਾਰੇ ਸਰਵਰ ਦੀ ਰਾਏ ਨਹੀਂ ਬਦਲੇਗੀ?

ਕੀ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਧਾਂਤਕ ਅਟਕਲਾਂ ਹਨ, ਅਤੇ ਅਭਿਆਸ ਵਿੱਚ ਅਜਿਹਾ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਕਿਉਂਕਿ ਸਰਵਰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਿਖਿਆ ਗਿਆ ਹੈ (ਘੱਟੋ ਘੱਟ, ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਟੈਸਟ ਕੀਤਾ ਗਿਆ ਹੈ)? ਹਾ! ਕੋਈ ਫ਼ਰਕ ਨਹੀਂ ਪੈਂਦਾ ਕਿ ਇਹ ਕਿਵੇਂ ਹੈ!

ਇਹ ਉਹੀ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਅਗਸਤ ਵਿੱਚ ਭੱਜੇ ਸੀ। 14 ਅਗਸਤ ਨੂੰ, ਅਜਿਹੇ ਸੁਨੇਹੇ ਸਨ ਕਿ ਟੈਲੀਗ੍ਰਾਮ ਸਰਵਰਾਂ 'ਤੇ ਕੁਝ ਅਪਡੇਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ... ਅਤੇ ਫਿਰ ਲੌਗਸ ਵਿੱਚ:

2019-08-15 09:28:35.880640 MSK warn  main: ANON:87: unknown object type: 0x80d182d1 at TL/Object.pm line 213.
2019-08-15 09:28:35.751899 MSK warn  main: ANON:87: unknown object type: 0xb5223b0f at TL/Object.pm line 213.

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

ਖੈਰ, ਪਹਿਲੀ ਚੀਜ਼ ਜੋ ਕਿਸੇ ਦੇ ਦਿਮਾਗ ਵਿੱਚ ਆਉਂਦੀ ਹੈ ਉਹ ਹੈ ਡਿਸਕਨੈਕਟ ਕਰਨਾ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ. ਮਦਦ ਨਹੀਂ ਕੀਤੀ। ਅਸੀਂ CRC32 ਗੂਗਲ ਕਰਦੇ ਹਾਂ - ਇਹ ਸਕੀਮ 73 ਤੋਂ ਆਬਜੈਕਟ ਨਿਕਲੇ, ਹਾਲਾਂਕਿ ਅਸੀਂ 82 'ਤੇ ਕੰਮ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਲੌਗਸ ਨੂੰ ਧਿਆਨ ਨਾਲ ਦੇਖਦੇ ਹਾਂ - ਦੋ ਵੱਖ-ਵੱਖ ਸਕੀਮਾਂ ਤੋਂ ਪਛਾਣਕਰਤਾ ਹਨ!

ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਸਾਡੇ ਅਣਅਧਿਕਾਰਤ ਗਾਹਕ ਵਿੱਚ ਹੈ? ਨਹੀਂ, ਅਸੀਂ ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟਾਪ 1.2.17 (ਕਈ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਸਪਲਾਈ ਕੀਤਾ ਸੰਸਕਰਣ) ਲਾਂਚ ਕਰਦੇ ਹਾਂ, ਇਹ ਅਪਵਾਦ ਲੌਗ ਵਿੱਚ ਲਿਖਦਾ ਹੈ: MTP ਅਣਕਿਆਸੀ ਕਿਸਮ id #b5223b0f MTPMessageMedia ਵਿੱਚ ਪੜ੍ਹਿਆ ਗਿਆ ਹੈ…

ਗੂਗਲ ਨੇ ਦਿਖਾਇਆ ਕਿ ਅਣਅਧਿਕਾਰਤ ਗਾਹਕਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਅਜਿਹੀ ਸਮੱਸਿਆ ਹੋ ਚੁੱਕੀ ਸੀ, ਪਰ ਫਿਰ ਸੰਸਕਰਣ ਨੰਬਰ ਅਤੇ, ਇਸਦੇ ਅਨੁਸਾਰ, ਧਾਰਨਾਵਾਂ ਵੱਖਰੀਆਂ ਸਨ ...

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

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

ਵਿਆਖਿਆ? ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਅਸਿੱਧੇ ਲੱਛਣਾਂ ਤੋਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕਦੇ ਹੋ, ਸਰਵਰ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਵੱਖ-ਵੱਖ ਕਿਸਮਾਂ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਸਰਵਰ ਜੋ "ਬਫਰਿੰਗ" ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਉਹ ਕਤਾਰ ਵਿੱਚ ਪਾ ਦਿੰਦਾ ਹੈ ਜੋ ਇਸਦੇ ਉੱਚ ਅਧਿਕਾਰੀਆਂ ਨੇ ਦਿੱਤਾ ਸੀ, ਅਤੇ ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਉਸ ਸਕੀਮ ਵਿੱਚ ਦਿੱਤਾ ਜੋ ਪੀੜ੍ਹੀ ਦੇ ਸਮੇਂ ਵਿੱਚ ਮੌਜੂਦ ਸੀ। ਅਤੇ ਜਦੋਂ ਤੱਕ ਇਹ ਕਤਾਰ "ਗੰਦੀ" ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਸੀ.

ਸ਼ਾਇਦ... ਪਰ ਇਹ ਇੱਕ ਭਿਆਨਕ ਬੈਸਾਖੀ ਹੈ?!.. ਨਹੀਂ, ਪਾਗਲ ਵਿਚਾਰਾਂ ਬਾਰੇ ਸੋਚਣ ਤੋਂ ਪਹਿਲਾਂ, ਆਓ ਅਧਿਕਾਰਤ ਗਾਹਕਾਂ ਦੇ ਕੋਡ ਨੂੰ ਵੇਖੀਏ. ਐਂਡਰੌਇਡ ਸੰਸਕਰਣ ਵਿੱਚ ਸਾਨੂੰ ਕੋਈ ਵੀ TL ਪਾਰਸਰ ਨਹੀਂ ਮਿਲਦਾ, ਪਰ ਸਾਨੂੰ (ਡੀ) ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਦੇ ਨਾਲ ਇੱਕ ਭਾਰੀ ਫਾਈਲ (GitHub ਇਸਨੂੰ ਛੂਹਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ) ਲੱਭਦੀ ਹੈ। ਇੱਥੇ ਕੋਡ ਸਨਿੱਪਟ ਹਨ:

public static class TL_message_layer68 extends TL_message {
    public static int constructor = 0xc09be45f;
//...
//еще пачка подобных
//...
    public static class TL_message_layer47 extends TL_message {
        public static int constructor = 0xc992e15c;
        public static Message TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
            Message result = null;
            switch (constructor) {
                case 0x1d86f70e:
                    result = new TL_messageService_old2();
                    break;
                case 0xa7ab1991:
                    result = new TL_message_old3();
                    break;
                case 0xc3060325:
                    result = new TL_message_old4();
                    break;
                case 0x555555fa:
                    result = new TL_message_secret();
                    break;
                case 0x555555f9:
                    result = new TL_message_secret_layer72();
                    break;
                case 0x90dddc11:
                    result = new TL_message_layer72();
                    break;
                case 0xc09be45f:
                    result = new TL_message_layer68();
                    break;
                case 0xc992e15c:
                    result = new TL_message_layer47();
                    break;
                case 0x5ba66c13:
                    result = new TL_message_old7();
                    break;
                case 0xc06b9607:
                    result = new TL_messageService_layer48();
                    break;
                case 0x83e5de54:
                    result = new TL_messageEmpty();
                    break;
                case 0x2bebfa86:
                    result = new TL_message_old6();
                    break;
                case 0x44f9b43d:
                    result = new TL_message_layer104();
                    break;
                case 0x1c9b1027:
                    result = new TL_message_layer104_2();
                    break;
                case 0xa367e716:
                    result = new TL_messageForwarded_old2(); //custom
                    break;
                case 0x5f46804:
                    result = new TL_messageForwarded_old(); //custom
                    break;
                case 0x567699b3:
                    result = new TL_message_old2(); //custom
                    break;
                case 0x9f8d60bb:
                    result = new TL_messageService_old(); //custom
                    break;
                case 0x22eb6aba:
                    result = new TL_message_old(); //custom
                    break;
                case 0x555555F8:
                    result = new TL_message_secret_old(); //custom
                    break;
                case 0x9789dac4:
                    result = new TL_message_layer104_3();
                    break;

ਜ

    boolean fixCaption = !TextUtils.isEmpty(message) &&
    (media instanceof TLRPC.TL_messageMediaPhoto_old ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer68 ||
     media instanceof TLRPC.TL_messageMediaPhoto_layer74 ||
     media instanceof TLRPC.TL_messageMediaDocument_old ||
     media instanceof TLRPC.TL_messageMediaDocument_layer68 ||
     media instanceof TLRPC.TL_messageMediaDocument_layer74)
    && message.startsWith("-1");

ਹਮ... ਜੰਗਲੀ ਲੱਗ ਰਿਹਾ ਹੈ। ਪਰ, ਸ਼ਾਇਦ, ਇਹ ਕੋਡ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਫਿਰ ਠੀਕ ਹੈ? .. ਪਰ ਇਹ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਾਰੇ ਸੰਸਕਰਣਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ! ਇਹ ਸੱਚ ਹੈ ਕਿ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ ਕਿ ਸਭ ਕੁਝ ਇਕੱਠੇ ਕਿਉਂ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਗੁਪਤ ਚੈਟ, ਅਤੇ ਹਰ ਤਰ੍ਹਾਂ ਦੇ _old7 ਕਿਸੇ ਤਰ੍ਹਾਂ ਮਸ਼ੀਨ ਜਨਰੇਸ਼ਨ ਵਰਗਾ ਨਹੀਂ ਲੱਗਦਾ... ਹਾਲਾਂਕਿ, ਸਭ ਤੋਂ ਵੱਧ ਮੈਂ ਉੱਡ ਗਿਆ ਸੀ

TL_message_layer104
TL_message_layer104_2
TL_message_layer104_3

ਦੋਸਤੋ, ਕੀ ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਵੀ ਨਹੀਂ ਕਰ ਸਕਦੇ ਕਿ ਇੱਕ ਪਰਤ ਦੇ ਅੰਦਰ ਕੀ ਹੈ?! ਖੈਰ, ਠੀਕ ਹੈ, ਮੰਨ ਲਓ ਕਿ "ਦੋ" ਇੱਕ ਗਲਤੀ ਨਾਲ ਜਾਰੀ ਕੀਤੇ ਗਏ ਸਨ, ਠੀਕ ਹੈ, ਅਜਿਹਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਤਿੰਨ?... ਉਸੇ ਵੇਲੇ, ਉਹੀ ਰੈਕ ਦੁਬਾਰਾ? ਇਹ ਕਿਹੋ ਜਿਹੀ ਅਸ਼ਲੀਲਤਾ ਹੈ, ਮਾਫ ਕਰਨਾ..?

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

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

ਠੀਕ ਹੈ, ਆਓ ਕੋਡ ਦੇ ਇੱਕ ਹੋਰ ਹਿੱਸੇ ਨੂੰ ਵੇਖੀਏ:

public static class TL_folders_deleteFolder extends TLObject {
    public static int constructor = 0x1c295881;

    public int folder_id;

    public TLObject deserializeResponse(AbstractSerializedData stream, int constructor, boolean exception) {
        return Updates.TLdeserialize(stream, constructor, exception);
    }

    public void serializeToStream(AbstractSerializedData stream) {
        stream.writeInt32(constructor);
        stream.writeInt32(folder_id);
    }
}

//manually created

//RichText start
public static abstract class RichText extends TLObject {
    public String url;
    public long webpage_id;
    public String email;
    public ArrayList<RichText> texts = new ArrayList<>();
    public RichText parentRichText;

    public static RichText TLdeserialize(AbstractSerializedData stream, int constructor, boolean exception) {
        RichText result = null;
        switch (constructor) {
            case 0x1ccb966a:
                result = new TL_textPhone();
                break;
            case 0xc7fb5e01:
                result = new TL_textSuperscript();
                break;

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

ਪਰ ਕਾਫ਼ੀ. ਆਓ ਉਸ ਪ੍ਰੋਟੋਕੋਲ 'ਤੇ ਚੱਲੀਏ ਜਿਸ ਦੇ ਸਿਖਰ 'ਤੇ ਇਹ ਸਾਰਾ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ ਚੱਲਦਾ ਹੈ.

ਐਮਟੀਪੀਟਰੋ

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

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

ਆਵਾਜਾਈ ਪਰਤ

ਪਹਿਲੀ ਗੱਲ ਆਵਾਜਾਈ ਹੈ. ਉਹ ਸਾਨੂੰ 5 ਵਿਕਲਪਾਂ ਬਾਰੇ ਦੱਸਣਗੇ:

• TCP
• ਵੈਬਸਾਕੇਟ
• HTTPS ਉੱਤੇ ਵੈਬਸਾਕੇਟ
• HTTP ਨੂੰ
• HTTPS

ਵੈਸੀਲੀ, [15.06.18 15:04] ਇੱਥੇ UDP ਟ੍ਰਾਂਸਪੋਰਟ ਵੀ ਹੈ, ਪਰ ਇਹ ਦਸਤਾਵੇਜ਼ੀ ਨਹੀਂ ਹੈ

ਅਤੇ ਤਿੰਨ ਰੂਪਾਂ ਵਿੱਚ ਟੀ.ਸੀ.ਪੀ

ਪਹਿਲਾ ਇੱਕ TCP ਉੱਤੇ UDP ਦੇ ਸਮਾਨ ਹੈ, ਹਰੇਕ ਪੈਕੇਟ ਵਿੱਚ ਇੱਕ ਕ੍ਰਮ ਨੰਬਰ ਅਤੇ crc ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ
ਕਾਰਟ 'ਤੇ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹਨਾ ਇੰਨਾ ਦਰਦਨਾਕ ਕਿਉਂ ਹੈ?

ਖੈਰ, ਇਹ ਹੁਣ ਹੈ TCP ਪਹਿਲਾਂ ਹੀ 4 ਰੂਪਾਂ ਵਿੱਚ ਹੈ:

• ਛੋਟਾ
• ਇੰਟਰਮੀਡੀਏਟ
• ਪੈਡਿਡ ਵਿਚਕਾਰਲਾ
• ਪੂਰਾ

ਖੈਰ, ਠੀਕ ਹੈ, MTProxy ਲਈ ਪੈਡਡ ਇੰਟਰਮੀਡੀਏਟ, ਇਹ ਬਾਅਦ ਵਿੱਚ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਘਟਨਾਵਾਂ ਦੇ ਕਾਰਨ ਜੋੜਿਆ ਗਿਆ ਸੀ। ਪਰ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਦੋ ਹੋਰ ਸੰਸਕਰਣ (ਕੁੱਲ ਵਿੱਚ ਤਿੰਨ) ਕਿਉਂ? ਸਾਰੇ ਚਾਰ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਮੁੱਖ MTProto ਦੀ ਲੰਬਾਈ ਅਤੇ ਪੇਲੋਡ ਨੂੰ ਕਿਵੇਂ ਸੈੱਟ ਕਰਨਾ ਹੈ ਇਸ ਵਿੱਚ ਵੱਖਰਾ ਹੈ, ਜਿਸ ਬਾਰੇ ਅੱਗੇ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ:

• ਸੰਖੇਪ ਵਿੱਚ ਇਹ 1 ਜਾਂ 4 ਬਾਈਟ ਹੈ, ਪਰ 0xef ਨਹੀਂ, ਫਿਰ ਸਰੀਰ
• ਇੰਟਰਮੀਡੀਏਟ ਵਿੱਚ ਇਹ ਲੰਬਾਈ ਦੇ 4 ਬਾਈਟ ਅਤੇ ਇੱਕ ਖੇਤਰ ਹੈ, ਅਤੇ ਪਹਿਲੀ ਵਾਰ ਗਾਹਕ ਨੂੰ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ 0xeeeeeeee ਇਹ ਦਰਸਾਉਣ ਲਈ ਕਿ ਇਹ ਇੰਟਰਮੀਡੀਏਟ ਹੈ
• ਇੱਕ ਨੈੱਟਵਰਕਰ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਸਭ ਤੋਂ ਵੱਧ ਆਦੀ ਹੈ: ਲੰਬਾਈ, ਕ੍ਰਮ ਨੰਬਰ, ਅਤੇ ਇੱਕ ਨਹੀਂ ਜੋ ਮੁੱਖ ਤੌਰ 'ਤੇ MTProto, body, CRC32 ਹੈ। ਹਾਂ, ਇਹ ਸਭ TCP ਦੇ ਸਿਖਰ 'ਤੇ ਹੈ। ਜੋ ਸਾਨੂੰ ਇੱਕ ਕ੍ਰਮਵਾਰ ਬਾਈਟ ਸਟ੍ਰੀਮ ਦੇ ਰੂਪ ਵਿੱਚ ਭਰੋਸੇਯੋਗ ਆਵਾਜਾਈ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਕਿਸੇ ਕ੍ਰਮ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਚੈਕਸਮਾਂ। ਠੀਕ ਹੈ, ਹੁਣ ਕੋਈ ਮੇਰੇ 'ਤੇ ਇਤਰਾਜ਼ ਕਰੇਗਾ ਕਿ TCP ਕੋਲ 16-ਬਿੱਟ ਚੈੱਕਸਮ ਹੈ, ਇਸਲਈ ਡੇਟਾ ਭ੍ਰਿਸ਼ਟਾਚਾਰ ਹੁੰਦਾ ਹੈ। ਬਹੁਤ ਵਧੀਆ, ਪਰ ਸਾਡੇ ਕੋਲ ਅਸਲ ਵਿੱਚ 16 ਬਾਈਟਾਂ ਤੋਂ ਵੱਧ ਲੰਬੇ ਹੈਸ਼ਾਂ ਵਾਲਾ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਪ੍ਰੋਟੋਕੋਲ ਹੈ, ਇਹ ਸਾਰੀਆਂ ਗਲਤੀਆਂ - ਅਤੇ ਹੋਰ ਵੀ - ਇੱਕ ਉੱਚ ਪੱਧਰ 'ਤੇ ਇੱਕ SHA ਬੇਮੇਲ ਦੁਆਰਾ ਫੜਿਆ ਜਾਵੇਗਾ. ਇਸ ਦੇ ਸਿਖਰ 'ਤੇ CRC32 ਵਿੱਚ ਕੋਈ ਬਿੰਦੂ ਨਹੀਂ ਹੈ।

ਆਉ ਸੰਖੇਪ ਦੀ ਤੁਲਨਾ ਕਰੀਏ, ਜਿਸ ਵਿੱਚ ਇੱਕ ਬਾਈਟ ਲੰਬਾਈ ਸੰਭਵ ਹੈ, ਇੰਟਰਮੀਡੀਏਟ ਨਾਲ, ਜੋ ਕਿ “4-ਬਾਈਟ ਡੇਟਾ ਅਲਾਈਨਮੈਂਟ ਦੀ ਲੋੜ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ” ਨੂੰ ਜਾਇਜ਼ ਠਹਿਰਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਕਾਫ਼ੀ ਬਕਵਾਸ ਹੈ। ਕੀ, ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਟੈਲੀਗ੍ਰਾਮ ਪ੍ਰੋਗਰਾਮਰ ਇੰਨੇ ਅਯੋਗ ਹਨ ਕਿ ਉਹ ਇੱਕ ਸਾਕਟ ਤੋਂ ਇੱਕ ਅਲਾਈਨਡ ਬਫਰ ਵਿੱਚ ਡੇਟਾ ਨਹੀਂ ਪੜ੍ਹ ਸਕਦੇ? ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਇਹ ਕਰਨਾ ਪਵੇਗਾ, ਕਿਉਂਕਿ ਪੜ੍ਹਨਾ ਤੁਹਾਨੂੰ ਕਿਸੇ ਵੀ ਗਿਣਤੀ ਵਿੱਚ ਬਾਈਟ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ (ਅਤੇ ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਵੀ ਹਨ, ਉਦਾਹਰਨ ਲਈ...)। ਜਾਂ ਦੂਜੇ ਪਾਸੇ, ਜੇ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ 16 ਬਾਈਟਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਭਾਰੀ ਪੈਡਿੰਗ ਹੋਵੇਗੀ ਤਾਂ ਕਿਉਂ ਬਲਾਕ ਕੀਤਾ ਗਿਆ ਹੈ - 3 ਬਾਈਟ ਬਚਾਓ ਕਦੇ ਕਦੇ ?

ਕਿਸੇ ਨੂੰ ਇਹ ਪ੍ਰਭਾਵ ਮਿਲਦਾ ਹੈ ਕਿ ਨਿਕੋਲਾਈ ਦੁਰੋਵ ਅਸਲ ਵਿੱਚ ਬਿਨਾਂ ਕਿਸੇ ਵਿਹਾਰਕ ਲੋੜ ਦੇ, ਨੈਟਵਰਕ ਪ੍ਰੋਟੋਕੋਲ ਸਮੇਤ, ਪਹੀਏ ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣਾ ਪਸੰਦ ਕਰਦਾ ਹੈ।

ਹੋਰ ਆਵਾਜਾਈ ਵਿਕਲਪ, ਸਮੇਤ। ਵੈੱਬ ਅਤੇ MTProxy, ਅਸੀਂ ਹੁਣ ਵਿਚਾਰ ਨਹੀਂ ਕਰਾਂਗੇ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਕਿਸੇ ਹੋਰ ਪੋਸਟ ਵਿੱਚ, ਜੇਕਰ ਕੋਈ ਬੇਨਤੀ ਹੈ. ਇਸੇ MTProxy ਬਾਰੇ, ਸਾਨੂੰ ਹੁਣੇ ਹੀ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ 2018 ਵਿੱਚ ਇਸ ਦੇ ਰਿਲੀਜ਼ ਹੋਣ ਤੋਂ ਥੋੜ੍ਹੀ ਦੇਰ ਬਾਅਦ, ਪ੍ਰਦਾਤਾਵਾਂ ਨੇ ਜਲਦੀ ਹੀ ਇਸਨੂੰ ਬਲਾਕ ਕਰਨਾ ਸਿੱਖ ਲਿਆ, ਜਿਸਦਾ ਉਦੇਸ਼ ਬਾਈਪਾਸ ਬਲਾਕਿੰਗ, ਤੇ ਪੈਕੇਜ ਦਾ ਆਕਾਰ! ਅਤੇ ਇਹ ਵੀ ਤੱਥ ਕਿ C ਵਿੱਚ ਲਿਖਿਆ MTProxy ਸਰਵਰ (ਦੁਬਾਰਾ ਵਾਲਟਮੈਨ ਦੁਆਰਾ) ਲੀਨਕਸ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜੁੜਿਆ ਹੋਇਆ ਸੀ, ਹਾਲਾਂਕਿ ਇਸਦੀ ਬਿਲਕੁਲ ਲੋੜ ਨਹੀਂ ਸੀ (ਫਿਲ ਕੁਲੀਨ ਪੁਸ਼ਟੀ ਕਰੇਗਾ), ਅਤੇ ਇਹ ਕਿ ਇੱਕ ਸਮਾਨ ਸਰਵਰ ਜਾਂ ਤਾਂ Go ਜਾਂ Node.js ਵਿੱਚ ਹੋਵੇਗਾ। ਸੌ ਤੋਂ ਘੱਟ ਲਾਈਨਾਂ ਵਿੱਚ ਫਿੱਟ.

ਪਰ ਅਸੀਂ ਹੋਰ ਮੁੱਦਿਆਂ 'ਤੇ ਵਿਚਾਰ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਭਾਗ ਦੇ ਅੰਤ ਵਿੱਚ ਇਹਨਾਂ ਲੋਕਾਂ ਦੀ ਤਕਨੀਕੀ ਸਾਖਰਤਾ ਬਾਰੇ ਸਿੱਟੇ ਕੱਢਾਂਗੇ। ਹੁਣ ਲਈ, ਆਓ OSI ਲੇਅਰ 5, ਸੈਸ਼ਨ 'ਤੇ ਚੱਲੀਏ - ਜਿਸ 'ਤੇ ਉਨ੍ਹਾਂ ਨੇ MTProto ਸੈਸ਼ਨ ਰੱਖਿਆ ਹੈ।

ਕੁੰਜੀਆਂ, ਸੁਨੇਹੇ, ਸੈਸ਼ਨ, ਡਿਫੀ-ਹੇਲਮੈਨ

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

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

ਕਹਿੰਦੇ ਹਨ ਦੋ ਸੰਸਥਾਵਾਂ ਹਨ ਸੈਸ਼ਨ - "ਮੌਜੂਦਾ ਸੈਸ਼ਨਾਂ" ਦੇ ਅਧੀਨ ਅਧਿਕਾਰਤ ਗਾਹਕਾਂ ਦੇ UI ਵਿੱਚ ਇੱਕ, ਜਿੱਥੇ ਹਰੇਕ ਸੈਸ਼ਨ ਇੱਕ ਪੂਰੇ ਡਿਵਾਈਸ / OS ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ।
ਦੂਜਾ - MTProto ਸੈਸ਼ਨ, ਜਿਸ ਵਿੱਚ ਸੁਨੇਹੇ ਦਾ ਕ੍ਰਮ ਸੰਖਿਆ (ਘੱਟ-ਪੱਧਰੀ ਅਰਥਾਂ ਵਿੱਚ) ਹੈ, ਅਤੇ ਕਿਹੜਾ ਵੱਖ-ਵੱਖ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ ਚੱਲ ਸਕਦਾ ਹੈ। ਕਈ MTProto ਸੈਸ਼ਨਾਂ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸਥਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਫਾਈਲ ਡਾਊਨਲੋਡਿੰਗ ਨੂੰ ਤੇਜ਼ ਕਰਨ ਲਈ।

ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਵਿਚਕਾਰ ਸੈਸ਼ਨ ਇੱਕ ਧਾਰਨਾ ਹੈ ਅਧਿਕਾਰ. ਡੀਜਨਰੇਟ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਕਹਿ ਸਕਦੇ ਹਾਂ ਕਿ UI ਸੈਸ਼ਨ ਦੇ ਸਮਾਨ ਹੈ ਅਧਿਕਾਰ, ਪਰ ਅਫ਼ਸੋਸ, ਸਭ ਕੁਝ ਗੁੰਝਲਦਾਰ ਹੈ. ਆਓ ਦੇਖੀਏ:

• ਨਵੀਂ ਡਿਵਾਈਸ 'ਤੇ ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਜਨਰੇਟ ਕਰਦਾ ਹੈ auth_key ਅਤੇ ਇਸਨੂੰ ਖਾਤੇ ਨਾਲ ਜੋੜਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ SMS ਦੁਆਰਾ - ਇਸ ਲਈ ਅਧਿਕਾਰ
• ਇਹ ਪਹਿਲੇ ਦੇ ਅੰਦਰ ਹੋਇਆ MTProto ਸੈਸ਼ਨ, ਜਿਸ ਕੋਲ ਹੈ session_id ਆਪਣੇ ਅੰਦਰ.
• ਇਸ ਕਦਮ 'ਤੇ, ਸੁਮੇਲ ਅਧਿਕਾਰ и session_id ਕਿਹਾ ਜਾ ਸਕਦਾ ਹੈ ਮਿਸਾਲ - ਇਹ ਸ਼ਬਦ ਕੁਝ ਗਾਹਕਾਂ ਦੇ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਕੋਡ ਵਿੱਚ ਪ੍ਰਗਟ ਹੁੰਦਾ ਹੈ
• ਫਿਰ, ਗਾਹਕ ਖੋਲ੍ਹ ਸਕਦਾ ਹੈ ਕਈ MTProto ਸੈਸ਼ਨ ਉਸੇ ਅਧੀਨ auth_key - ਉਸੇ ਡੀਸੀ ਨੂੰ.
• ਫਿਰ, ਇੱਕ ਦਿਨ ਗਾਹਕ ਨੂੰ ਫਾਈਲ ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ ਇੱਕ ਹੋਰ ਡੀ.ਸੀ - ਅਤੇ ਇਸਦੇ ਲਈ ਇੱਕ ਨਵਾਂ DC ਤਿਆਰ ਕੀਤਾ ਜਾਵੇਗਾ auth_key !
• ਸਿਸਟਮ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਲਈ ਕਿ ਇਹ ਕੋਈ ਨਵਾਂ ਉਪਭੋਗਤਾ ਨਹੀਂ ਹੈ ਜੋ ਰਜਿਸਟਰ ਕਰ ਰਿਹਾ ਹੈ, ਪਰ ਉਹੀ ਹੈ ਅਧਿਕਾਰ (UI ਸੈਸ਼ਨ), ਕਲਾਇੰਟ API ਕਾਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ auth.exportAuthorization ਘਰ ਵਿੱਚ ਡੀ.ਸੀ auth.importAuthorization ਨਵੇਂ ਡੀਸੀ ਵਿੱਚ
• ਸਭ ਕੁਝ ਇੱਕੋ ਜਿਹਾ ਹੈ, ਕਈ ਖੁੱਲ੍ਹ ਸਕਦੇ ਹਨ MTProto ਸੈਸ਼ਨ (ਹਰੇਕ ਆਪਣੇ ਨਾਲ session_id) ਨੂੰ ਇਸ ਨਵੇਂ ਡੀ.ਸੀ., ਅਧੀਨ ਉਸ ਦੇ auth_key.
• ਅੰਤ ਵਿੱਚ, ਗਾਹਕ ਸੰਪੂਰਨ ਫਾਰਵਰਡ ਗੁਪਤਤਾ ਚਾਹੁੰਦਾ ਹੈ। ਹਰ auth_key ਸੀ ਸਥਾਈ ਕੁੰਜੀ - ਪ੍ਰਤੀ DC - ਅਤੇ ਕਲਾਇੰਟ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ auth.bindTempAuthKey ਵਰਤਣ ਲਈ ਆਰਜ਼ੀ auth_key - ਅਤੇ ਦੁਬਾਰਾ, ਸਿਰਫ ਇੱਕ temp_auth_key ਪ੍ਰਤੀ DC, ਸਾਰਿਆਂ ਲਈ ਸਾਂਝਾ MTProto ਸੈਸ਼ਨ ਇਸ ਡੀ.ਸੀ.

ਨੋਟ ਕਰੋ ਲੂਣ (ਅਤੇ ਭਵਿੱਖ ਦੇ ਲੂਣ) ਵੀ ਇੱਕ ਹੈ auth_key ਉਹ. ਸਾਰਿਆਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਕੀਤਾ MTProto ਸੈਸ਼ਨ ਉਸੇ ਡੀਸੀ ਨੂੰ.

"ਵੱਖ-ਵੱਖ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ? ਇਸ ਲਈ ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕੁਝ ਅਜਿਹਾ ਇੱਕ ਵੈਬਸਾਈਟ 'ਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਕੂਕੀ - ਇਹ ਇੱਕ ਦਿੱਤੇ ਸਰਵਰ ਨਾਲ ਬਹੁਤ ਸਾਰੇ TCP ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ (ਬਚਦਾ ਹੈ), ਪਰ ਇੱਕ ਦਿਨ ਇਹ ਖਰਾਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਸਿਰਫ਼ HTTP ਦੇ ਉਲਟ, MTProto ਵਿੱਚ ਇੱਕ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਕ੍ਰਮਵਾਰ ਨੰਬਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਜੇਕਰ ਉਹ ਸੁਰੰਗ ਵਿੱਚ ਦਾਖਲ ਹੁੰਦੇ ਹਨ, ਤਾਂ ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਗਿਆ ਸੀ - ਇੱਕ ਨਵਾਂ ਕਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਕਿਰਪਾ ਕਰਕੇ ਇਸ ਸੈਸ਼ਨ ਵਿੱਚ ਉਹ ਸਭ ਕੁਝ ਭੇਜੇਗਾ ਜੋ ਇਸਨੇ ਪਿਛਲੇ ਵਿੱਚ ਨਹੀਂ ਦਿੱਤਾ ਸੀ। TCP ਕਨੈਕਸ਼ਨ।

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

ਇਸ ਲਈ ਆਓ ਪੈਦਾ ਕਰੀਏ auth_key 'ਤੇ ਟੈਲੀਗ੍ਰਾਮ ਤੋਂ ਡਿਫੀ-ਹੇਲਮੈਨ ਸੰਸਕਰਣ. ਆਓ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ...

ਵੈਸੀਲੀ, [19.06.18 20:05] data_with_hash := SHA1(ਡਾਟਾ) + ਡੇਟਾ + (ਕੋਈ ਵੀ ਬੇਤਰਤੀਬ ਬਾਈਟਸ); ਜਿਵੇਂ ਕਿ ਲੰਬਾਈ 255 ਬਾਈਟ ਦੇ ਬਰਾਬਰ ਹੈ;
encrypted_data := RSA(data_with_hash, server_public_key); ਇੱਕ 255-ਬਾਈਟ ਲੰਬੇ ਨੰਬਰ (ਵੱਡੇ ਐਂਡੀਅਨ) ਨੂੰ ਲੋੜੀਂਦੇ ਮਾਡਿਊਲਸ ਉੱਤੇ ਲੋੜੀਂਦੀ ਸ਼ਕਤੀ ਤੱਕ ਵਧਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨਤੀਜਾ ਇੱਕ 256-ਬਾਈਟ ਨੰਬਰ ਵਜੋਂ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਉਨ੍ਹਾਂ ਨੂੰ ਕੁਝ ਡੋਪ ਡੀ.ਐਚ

ਇੱਕ ਸਿਹਤਮੰਦ ਵਿਅਕਤੀ ਦਾ DH ਨਹੀਂ ਲੱਗਦਾ
dx ਵਿੱਚ ਕੋਈ ਦੋ ਜਨਤਕ ਕੁੰਜੀਆਂ ਨਹੀਂ ਹਨ

ਖੈਰ, ਅੰਤ ਵਿੱਚ ਇਸ ਨੂੰ ਸੁਲਝਾਇਆ ਗਿਆ ਸੀ, ਪਰ ਇੱਕ ਰਹਿੰਦ-ਖੂੰਹਦ ਬਚੀ ਸੀ - ਕੰਮ ਦਾ ਸਬੂਤ ਗਾਹਕ ਦੁਆਰਾ ਕੀਤਾ ਗਿਆ ਹੈ ਕਿ ਉਹ ਸੰਖਿਆ ਨੂੰ ਕਾਰਕ ਕਰਨ ਦੇ ਯੋਗ ਸੀ। DoS ਹਮਲਿਆਂ ਤੋਂ ਸੁਰੱਖਿਆ ਦੀ ਕਿਸਮ। ਅਤੇ RSA ਕੁੰਜੀ ਸਿਰਫ ਇੱਕ ਵਾਰ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਲਈ new_nonce. ਪਰ ਜਦੋਂ ਕਿ ਇਹ ਪ੍ਰਤੀਤ ਹੁੰਦਾ ਸਧਾਰਨ ਕਾਰਵਾਈ ਸਫਲ ਹੋ ਜਾਵੇਗੀ, ਤੁਹਾਨੂੰ ਕਿਸ ਚੀਜ਼ ਦਾ ਸਾਮ੍ਹਣਾ ਕਰਨਾ ਪਵੇਗਾ?

ਵੈਸੀਲੀ, [20.06.18/00/26 XNUMX:XNUMX] ਮੈਂ ਅਜੇ ਤੱਕ ਐਪਿਡ ਬੇਨਤੀ ਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਹੈ

ਮੈਂ ਇਹ ਬੇਨਤੀ ਡੀ.ਐਚ

ਅਤੇ, ਟ੍ਰਾਂਸਪੋਰਟ ਡੌਕ ਵਿੱਚ ਇਹ ਕਹਿੰਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਗਲਤੀ ਕੋਡ ਦੇ 4 ਬਾਈਟਸ ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ. ਇਹ ਸਭ ਹੈ

ਖੈਰ, ਉਸਨੇ ਮੈਨੂੰ ਦੱਸਿਆ -404, ਤਾਂ ਕੀ?

ਇਸ ਲਈ ਮੈਂ ਉਸਨੂੰ ਕਿਹਾ: "ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਫਿੰਗਰਪ੍ਰਿੰਟ ਨਾਲ ਸਰਵਰ ਕੁੰਜੀ ਨਾਲ ਏਨਕ੍ਰਿਪਟ ਕੀਤੀ ਆਪਣੀ ਬੁੱਲਿਸ਼ਟ ਨੂੰ ਫੜੋ, ਮੈਨੂੰ DH ਚਾਹੀਦਾ ਹੈ," ਅਤੇ ਇਸਨੇ ਇੱਕ ਮੂਰਖ 404 ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ

ਤੁਸੀਂ ਇਸ ਸਰਵਰ ਜਵਾਬ ਬਾਰੇ ਕੀ ਸੋਚੋਗੇ? ਮੈਂ ਕੀ ਕਰਾਂ? ਕੋਈ ਪੁੱਛਣ ਵਾਲਾ ਨਹੀਂ ਹੈ (ਪਰ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ)।

ਏਥੇ ਸਾਰਾ ਵਿਆਜ ਡੱਕੇ 'ਤੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਮੇਰੇ ਕੋਲ ਕਰਨ ਲਈ ਹੋਰ ਕੁਝ ਨਹੀਂ ਹੈ, ਮੈਂ ਸਿਰਫ ਨੰਬਰਾਂ ਨੂੰ ਅੱਗੇ ਅਤੇ ਪਿੱਛੇ ਬਦਲਣ ਦਾ ਸੁਪਨਾ ਦੇਖਿਆ ਹੈ

ਦੋ 32 ਬਿੱਟ ਨੰਬਰ। ਮੈਂ ਉਨ੍ਹਾਂ ਨੂੰ ਹਰ ਕਿਸੇ ਵਾਂਗ ਪੈਕ ਕੀਤਾ

ਪਰ ਨਹੀਂ, ਇਹਨਾਂ ਦੋਵਾਂ ਨੂੰ ਪਹਿਲਾਂ BE ਦੇ ਰੂਪ ਵਿੱਚ ਲਾਈਨ ਵਿੱਚ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ

Vadim Goncharov, [20.06.18 15:49] ਅਤੇ ਇਸ ਕਰਕੇ 404?

ਵੈਸੀਲੀ, [20.06.18 15:49] ਹਾਂ!

Vadim Goncharov, [20.06.18 15:50] ਇਸ ਲਈ ਮੈਨੂੰ ਸਮਝ ਨਹੀਂ ਆਉਂਦੀ ਕਿ ਉਹ ਕੀ "ਲੱਭ ਨਹੀਂ ਸਕਿਆ"

ਵੈਸੀਲੀ, [20.06.18 15:50] ਲਗਭਗ

ਮੈਂ ਪ੍ਰਮੁੱਖ ਕਾਰਕਾਂ% ਵਿੱਚ ਅਜਿਹਾ ਵਿਘਨ ਨਹੀਂ ਲੱਭ ਸਕਿਆ)

ਅਸੀਂ ਗਲਤੀ ਰਿਪੋਰਟਿੰਗ ਦਾ ਪ੍ਰਬੰਧਨ ਵੀ ਨਹੀਂ ਕੀਤਾ

ਵੈਸੀਲੀ, [20.06.18 20:18] ਓ, ਇੱਥੇ MD5 ਵੀ ਹੈ। ਪਹਿਲਾਂ ਹੀ ਤਿੰਨ ਵੱਖ-ਵੱਖ ਹੈਸ਼

ਕੁੰਜੀ ਫਿੰਗਰਪ੍ਰਿੰਟ ਦੀ ਗਣਨਾ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

digest = md5(key + iv)
fingerprint = substr(digest, 0, 4) XOR substr(digest, 4, 4)

SHA1 ਅਤੇ sha2

ਇਸ ਲਈ ਇਸ ਨੂੰ ਪਾ ਦਿਓ auth_key ਅਸੀਂ ਡਿਫੀ-ਹੇਲਮੈਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਆਕਾਰ ਵਿੱਚ 2048 ਬਿੱਟ ਪ੍ਰਾਪਤ ਕੀਤੇ। ਅੱਗੇ ਕੀ ਹੈ? ਅੱਗੇ ਅਸੀਂ ਖੋਜਦੇ ਹਾਂ ਕਿ ਇਸ ਕੁੰਜੀ ਦੇ ਹੇਠਲੇ 1024 ਬਿੱਟ ਕਿਸੇ ਵੀ ਤਰੀਕੇ ਨਾਲ ਨਹੀਂ ਵਰਤੇ ਗਏ ਹਨ... ਪਰ ਆਓ ਇਸ ਬਾਰੇ ਹੁਣੇ ਸੋਚੀਏ। ਇਸ ਪੜਾਅ 'ਤੇ, ਸਾਡੇ ਕੋਲ ਸਰਵਰ ਨਾਲ ਸਾਂਝਾ ਰਾਜ਼ ਹੈ। TLS ਸੈਸ਼ਨ ਦਾ ਇੱਕ ਐਨਾਲਾਗ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਬਹੁਤ ਮਹਿੰਗਾ ਪ੍ਰਕਿਰਿਆ ਹੈ. ਪਰ ਸਰਵਰ ਅਜੇ ਵੀ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਅਸੀਂ ਕੌਣ ਹਾਂ! ਅਜੇ ਨਹੀਂ, ਅਸਲ ਵਿੱਚ. ਅਧਿਕਾਰ. ਉਹ. ਜੇਕਰ ਤੁਸੀਂ “ਲੌਗਿਨ-ਪਾਸਵਰਡ” ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚਿਆ ਸੀ, ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਇੱਕ ਵਾਰ ICQ ਵਿੱਚ ਕੀਤਾ ਸੀ, ਜਾਂ ਘੱਟੋ-ਘੱਟ “ਲੌਗਿਨ-ਕੁੰਜੀ”, ਜਿਵੇਂ ਕਿ SSH ਵਿੱਚ (ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਗਿਟਲਬ/ਗਿਥਬ ਉੱਤੇ)। ਸਾਨੂੰ ਇੱਕ ਅਗਿਆਤ ਪ੍ਰਾਪਤ ਹੋਇਆ। ਜੇ ਸਰਵਰ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ "ਇਹ ਫ਼ੋਨ ਨੰਬਰ ਕਿਸੇ ਹੋਰ DC ਦੁਆਰਾ ਸੇਵਾ ਕੀਤੇ ਗਏ ਹਨ"? ਜਾਂ ਇੱਥੋਂ ਤੱਕ ਕਿ "ਤੁਹਾਡੇ ਫ਼ੋਨ ਨੰਬਰ 'ਤੇ ਪਾਬੰਦੀ ਲਗਾਈ ਗਈ ਹੈ"? ਸਭ ਤੋਂ ਵਧੀਆ ਅਸੀਂ ਇਹ ਕਰ ਸਕਦੇ ਹਾਂ ਕਿ ਕੁੰਜੀ ਨੂੰ ਇਸ ਉਮੀਦ ਵਿੱਚ ਰੱਖਣਾ ਹੈ ਕਿ ਇਹ ਉਪਯੋਗੀ ਹੋਵੇਗੀ ਅਤੇ ਉਦੋਂ ਤੱਕ ਖਰਾਬ ਨਹੀਂ ਹੋਵੇਗੀ।

ਤਰੀਕੇ ਨਾਲ, ਅਸੀਂ ਇਸਨੂੰ ਰਿਜ਼ਰਵੇਸ਼ਨ ਨਾਲ "ਪ੍ਰਾਪਤ" ਕੀਤਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਕੀ ਅਸੀਂ ਸਰਵਰ 'ਤੇ ਭਰੋਸਾ ਕਰਦੇ ਹਾਂ? ਕੀ ਜੇ ਇਹ ਜਾਅਲੀ ਹੈ? ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਜਾਂਚਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ:

ਵੈਸੀਲੀ, [21.06.18 17:53] ਉਹ ਮੋਬਾਈਲ ਗਾਹਕਾਂ ਨੂੰ ਪ੍ਰਮੁੱਖਤਾ% ਲਈ 2kbit ਨੰਬਰ ਦੀ ਜਾਂਚ ਕਰਨ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦੇ ਹਨ)

ਪਰ ਇਹ ਬਿਲਕੁਲ ਵੀ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ, ਨਫੀਜੋਆ

ਵੈਸੀਲੀ, [21.06.18 18:02] ਦਸਤਾਵੇਜ਼ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿ ਜੇ ਇਹ ਸਧਾਰਨ ਨਹੀਂ ਹੁੰਦਾ ਤਾਂ ਕੀ ਕਰਨਾ ਹੈ

ਕਿਹਾ ਨਹੀਂ। ਆਓ ਦੇਖੀਏ ਕਿ ਅਧਿਕਾਰਤ ਐਂਡਰੌਇਡ ਕਲਾਇੰਟ ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ? ਏ ਜੋ ਕਿ ਹੈ (ਅਤੇ ਹਾਂ, ਪੂਰੀ ਫਾਈਲ ਦਿਲਚਸਪ ਹੈ) - ਜਿਵੇਂ ਕਿ ਉਹ ਕਹਿੰਦੇ ਹਨ, ਮੈਂ ਇਸਨੂੰ ਇੱਥੇ ਛੱਡਾਂਗਾ:

278     static const char *goodPrime = "c71caeb9c6b1c9048e6c522f70f13f73980d40238e3e21c14934d037563d930f48198a0aa7c14058229493d22530f4dbfa336f6e0ac925139543aed44cce7c3720fd51f69458705ac68cd4fe6b6b13abdc9746512969328454f18faf8c595f642477fe96bb2a941d5bcd1d4ac8cc49880708fa9b378e3c4f3a9060bee67cf9a4a4a695811051907e162753b56b0f6b410dba74d8a84b2a14b3144e0ef1284754fd17ed950d5965b4b9dd46582db1178d169c6bc465b0d6ff9ca3928fef5b9ae4e418fc15e83ebea0f87fa9ff5eed70050ded2849f47bf959d956850ce929851f0d8115f635b105ee2e4e15d04b2454bf6f4fadf034b10403119cd8e3b92fcc5b";
279   if (!strcasecmp(prime, goodPrime)) {

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

ਠੀਕ ਹੈ, ਸਾਨੂੰ ਮਾਸਟਰ ਕੁੰਜੀ ਮਿਲ ਗਈ ਹੈ। ਲੌਗ ਇਨ ਕਰਨ ਲਈ, i.e. ਬੇਨਤੀਆਂ ਭੇਜੋ, ਤੁਹਾਨੂੰ AES ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਹੋਰ ਏਨਕ੍ਰਿਪਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਮੈਸੇਜ ਕੁੰਜੀ ਨੂੰ ਮੈਸੇਜ ਬਾਡੀ ਦੇ SHA128 ਦੇ 256 ਮੱਧ ਬਿੱਟਾਂ ਦੇ ਤੌਰ 'ਤੇ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ (ਸਮੇਤ ਸ਼ੈਸ਼ਨ, ਸੁਨੇਹਾ ID, ਆਦਿ), ਪੈਡਿੰਗ ਬਾਈਟਾਂ ਸਮੇਤ, ਪ੍ਰਮਾਣਿਕਤਾ ਕੁੰਜੀ ਤੋਂ ਲਏ ਗਏ 32 ਬਾਈਟਾਂ ਦੁਆਰਾ ਪਹਿਲਾਂ-ਪੇਸ਼ ਕੀਤੇ ਗਏ।

ਵੈਸੀਲੀ, [22.06.18 14:08] ਔਸਤ, ਕੁੱਕੜ, ਬਿੱਟ

ਮਿਲੀ auth_key. ਸਾਰੇ। ਉਹਨਾਂ ਤੋਂ ਪਰੇ... ਇਹ ਦਸਤਾਵੇਜ਼ ਤੋਂ ਸਪੱਸ਼ਟ ਨਹੀਂ ਹੈ। ਓਪਨ ਸੋਰਸ ਕੋਡ ਦਾ ਅਧਿਐਨ ਕਰਨ ਲਈ ਬੇਝਿਜਕ ਮਹਿਸੂਸ ਕਰੋ।

ਨੋਟ ਕਰੋ ਕਿ MTProto 2.0 ਨੂੰ ਪੈਡਿੰਗ ਦੇ 12 ਤੋਂ 1024 ਬਾਈਟਸ ਦੀ ਲੋੜ ਹੈ, ਫਿਰ ਵੀ ਇਸ ਸ਼ਰਤ ਦੇ ਅਧੀਨ ਹੈ ਕਿ ਨਤੀਜੇ ਵਜੋਂ ਸੰਦੇਸ਼ ਦੀ ਲੰਬਾਈ 16 ਬਾਈਟਾਂ ਨਾਲ ਵੰਡੀ ਜਾ ਸਕਦੀ ਹੈ।

ਤਾਂ ਤੁਹਾਨੂੰ ਕਿੰਨਾ ਪੈਡਿੰਗ ਜੋੜਨਾ ਚਾਹੀਦਾ ਹੈ?

ਅਤੇ ਹਾਂ, ਇੱਕ ਗਲਤੀ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇੱਕ 404 ਵੀ ਹੈ

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

ਮੈਂ ਇੱਕ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਰ ਨਹੀਂ ਹਾਂ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਸਿਧਾਂਤਕ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਇਸ ਕੇਸ ਵਿੱਚ ਇਸ ਮੋਡ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ. ਪਰ ਮੈਂ ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟੌਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੱਕ ਵਿਹਾਰਕ ਸਮੱਸਿਆ ਦਾ ਨਾਮ ਦੇ ਸਕਦਾ ਹਾਂ। ਇਹ ਸਥਾਨਕ ਕੈਸ਼ (ਇਹ ਸਾਰੇ D877F783D5D3EF8C) ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ MTProto (ਸਿਰਫ਼ ਇਸ ਕੇਸ ਦੇ ਸੰਸਕਰਣ 1.0 ਵਿੱਚ), ਜਿਵੇਂ ਕਿ ਸੁਨੇਹੇ। ਪਹਿਲਾਂ ਸੁਨੇਹਾ ਕੁੰਜੀ, ਫਿਰ ਡੇਟਾ ਆਪਣੇ ਆਪ (ਅਤੇ ਕਿਤੇ ਇੱਕ ਪਾਸੇ ਮੁੱਖ ਵੱਡਾ auth_key 256 ਬਾਈਟ, ਜਿਸ ਤੋਂ ਬਿਨਾਂ msg_key ਬੇਕਾਰ). ਇਸ ਲਈ, ਸਮੱਸਿਆ ਵੱਡੀਆਂ ਫਾਈਲਾਂ 'ਤੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਬਣ ਜਾਂਦੀ ਹੈ. ਅਰਥਾਤ, ਤੁਹਾਨੂੰ ਡੇਟਾ ਦੀਆਂ ਦੋ ਕਾਪੀਆਂ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਐਨਕ੍ਰਿਪਟਡ ਅਤੇ ਡੀਕ੍ਰਿਪਟਡ। ਅਤੇ ਜੇਕਰ ਮੈਗਾਬਾਈਟ, ਜਾਂ ਸਟ੍ਰੀਮਿੰਗ ਵੀਡੀਓ ਹਨ, ਉਦਾਹਰਨ ਲਈ?... ਸਾਈਫਰਟੈਕਸਟ ਦੇ ਬਾਅਦ MAC ਨਾਲ ਕਲਾਸਿਕ ਸਕੀਮਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਤੁਰੰਤ ਪ੍ਰਸਾਰਿਤ ਕਰਨ, ਇਸਨੂੰ ਸਟ੍ਰੀਮ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ। ਪਰ MTProto ਦੇ ਨਾਲ ਤੁਹਾਨੂੰ ਇਹ ਕਰਨਾ ਹੋਵੇਗਾ ਪਹਿਲਾਂ ਪੂਰੇ ਸੁਨੇਹੇ ਨੂੰ ਐਨਕ੍ਰਿਪਟ ਜਾਂ ਡੀਕ੍ਰਿਪਟ ਕਰੋ, ਕੇਵਲ ਤਦ ਹੀ ਇਸਨੂੰ ਨੈਟਵਰਕ ਜਾਂ ਡਿਸਕ ਤੇ ਟ੍ਰਾਂਸਫਰ ਕਰੋ। ਇਸ ਲਈ, ਕੈਸ਼ ਵਿੱਚ ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟਾਪ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਵਿੱਚ user_data ਇੱਕ ਹੋਰ ਫਾਰਮੈਟ ਵੀ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ - CTR ਮੋਡ ਵਿੱਚ AES ਦੇ ਨਾਲ।

ਵੈਸੀਲੀ, [21.06.18 01:27] ਓਹ, ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ IGE ਕੀ ਹੈ: IGE ਇੱਕ "ਪ੍ਰਮਾਣਿਤ ਏਨਕ੍ਰਿਪਸ਼ਨ ਮੋਡ" ਦੀ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਸੀ, ਅਸਲ ਵਿੱਚ ਕਰਬੇਰੋਸ ਲਈ। ਇਹ ਇੱਕ ਅਸਫਲ ਕੋਸ਼ਿਸ਼ ਸੀ (ਇਹ ਅਖੰਡਤਾ ਸੁਰੱਖਿਆ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ), ਅਤੇ ਇਸਨੂੰ ਹਟਾਉਣਾ ਪਿਆ। ਇਹ ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਐਨਕ੍ਰਿਪਸ਼ਨ ਮੋਡ ਲਈ 20 ਸਾਲਾਂ ਦੀ ਖੋਜ ਦੀ ਸ਼ੁਰੂਆਤ ਸੀ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ ਹਾਲ ਹੀ ਵਿੱਚ OCB ਅਤੇ GCM ਵਰਗੇ ਮੋਡਾਂ ਵਿੱਚ ਸਮਾਪਤ ਹੋਇਆ ਹੈ।

ਅਤੇ ਹੁਣ ਕਾਰਟ ਵਾਲੇ ਪਾਸੇ ਤੋਂ ਦਲੀਲਾਂ:

ਟੈਲੀਗ੍ਰਾਮ ਦੇ ਪਿੱਛੇ ਦੀ ਟੀਮ, ਨਿਕੋਲਾਈ ਦੁਰੋਵ ਦੀ ਅਗਵਾਈ ਵਿੱਚ, ਛੇ ਏਸੀਐਮ ਚੈਂਪੀਅਨ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਅੱਧੇ ਗਣਿਤ ਵਿੱਚ ਪੀਐਚ.ਡੀ. MTProto ਦੇ ਮੌਜੂਦਾ ਸੰਸਕਰਣ ਨੂੰ ਰੋਲ ਆਊਟ ਕਰਨ ਵਿੱਚ ਉਨ੍ਹਾਂ ਨੂੰ ਲਗਭਗ ਦੋ ਸਾਲ ਲੱਗੇ।

ਇਹ ਤਾਂ ਮਜੇਦਾਰ ਹੈ. ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਦੋ ਸਾਲ

ਜਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ tls ਲੈ ਸਕਦੇ ਹੋ

ਠੀਕ ਹੈ, ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਏਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਹੋਰ ਸੂਖਮਤਾਵਾਂ ਕੀਤੀਆਂ ਹਨ। ਕੀ ਅੰਤ ਵਿੱਚ TL ਵਿੱਚ ਲੜੀਬੱਧ ਬੇਨਤੀਆਂ ਭੇਜਣਾ ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਡੀਸੀਰੀਅਲਾਈਜ਼ ਕਰਨਾ ਸੰਭਵ ਹੈ? ਤਾਂ ਤੁਹਾਨੂੰ ਕੀ ਅਤੇ ਕਿਵੇਂ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ? ਇੱਥੇ, ਦੱਸ ਦੇਈਏ, ਵਿਧੀ initConnection, ਸ਼ਾਇਦ ਇਹ ਹੈ?

ਵੈਸੀਲੀ, [25.06.18 18:46] ਕੁਨੈਕਸ਼ਨ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਦੇ ਡਿਵਾਈਸ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਜਾਣਕਾਰੀ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।

ਇਹ app_id, device_model, system_version, app_version ਅਤੇ lang_code ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ।

ਅਤੇ ਕੁਝ ਸਵਾਲ

ਹਮੇਸ਼ਾ ਵਾਂਗ ਦਸਤਾਵੇਜ਼। ਖੁੱਲ੍ਹੇ ਸਰੋਤ ਦਾ ਅਧਿਐਨ ਕਰਨ ਲਈ ਮੁਫ਼ਤ ਮਹਿਸੂਸ ਕਰੋ

ਜੇਕਰ invokeWithLayer ਨਾਲ ਸਭ ਕੁਝ ਲਗਭਗ ਸਪੱਸ਼ਟ ਸੀ, ਤਾਂ ਇੱਥੇ ਕੀ ਗਲਤ ਹੈ? ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ, ਮੰਨ ਲਓ ਸਾਡੇ ਕੋਲ ਹੈ - ਕਲਾਇੰਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਰਵਰ ਨੂੰ ਪੁੱਛਣ ਲਈ ਕੁਝ ਸੀ - ਇੱਕ ਬੇਨਤੀ ਹੈ ਜੋ ਅਸੀਂ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਸੀ:

ਵੈਸੀਲੀ, [25.06.18 19:13] ਕੋਡ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਪਹਿਲੀ ਕਾਲ ਨੂੰ ਇਸ ਬਕਵਾਸ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਕਵਾਸ ਆਪਣੇ ਆਪ ਨੂੰ ਇਨਵੋਕਵਿਥਲੇਅਰ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ

initConnection ਇੱਕ ਵੱਖਰੀ ਕਾਲ ਕਿਉਂ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਪਰ ਇੱਕ ਰੈਪਰ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ? ਹਾਂ, ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, ਇਹ ਹਰ ਵਾਰ ਹਰ ਸੈਸ਼ਨ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਇੱਕ ਵਾਰ, ਜਿਵੇਂ ਕਿ ਮੁੱਖ ਕੁੰਜੀ ਦੇ ਨਾਲ। ਪਰ! ਇਸਨੂੰ ਅਣਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਨਹੀਂ ਬੁਲਾਇਆ ਜਾ ਸਕਦਾ ਹੈ! ਹੁਣ ਅਸੀਂ ਉਸ ਪੜਾਅ 'ਤੇ ਪਹੁੰਚ ਗਏ ਹਾਂ ਜਿੱਥੇ ਇਹ ਲਾਗੂ ਹੁੰਦਾ ਹੈ ਇਹ ਵਾਲਾ ਦਸਤਾਵੇਜ਼ੀ ਪੰਨਾ - ਅਤੇ ਇਹ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ...

API ਵਿਧੀਆਂ ਦਾ ਸਿਰਫ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਹਿੱਸਾ ਅਣਅਧਿਕਾਰਤ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਉਪਲਬਧ ਹੈ:

• auth.sendCode
• auth.resendCode
• account.getPassword
• auth.checkPassword
• auth.checkPhone
• auth.signUp
• auth.signIn
• auth.importAuthorization
• help.getConfig
• help.getNearestDc
• help.getAppUpdate
• help.getCdnConfig
• langpack.getLangPack
• langpack.getStrings
• langpack.getDifference
• langpack.getLanguages
• langpack.getLanguage

ਉਨ੍ਹਾਂ ਵਿਚੋਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ, auth.sendCode, ਅਤੇ ਇੱਥੇ ਉਹ ਪਿਆਰੀ ਪਹਿਲੀ ਬੇਨਤੀ ਹੈ ਜਿਸ ਵਿੱਚ ਅਸੀਂ api_id ਅਤੇ api_hash ਭੇਜਦੇ ਹਾਂ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਸਾਨੂੰ ਇੱਕ ਕੋਡ ਦੇ ਨਾਲ ਇੱਕ SMS ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਜੇਕਰ ਅਸੀਂ ਗਲਤ DC ਵਿੱਚ ਹਾਂ (ਉਦਾਹਰਣ ਲਈ, ਇਸ ਦੇਸ਼ ਵਿੱਚ ਟੈਲੀਫੋਨ ਨੰਬਰ ਕਿਸੇ ਹੋਰ ਦੁਆਰਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ), ਤਾਂ ਸਾਨੂੰ ਲੋੜੀਂਦੇ DC ਦੇ ਨੰਬਰ ਨਾਲ ਇੱਕ ਤਰੁੱਟੀ ਪ੍ਰਾਪਤ ਹੋਵੇਗੀ। ਇਹ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਿ DC ਨੰਬਰ ਦੁਆਰਾ ਤੁਹਾਨੂੰ ਕਿਹੜੇ IP ਪਤੇ ਨਾਲ ਜੁੜਨ ਦੀ ਲੋੜ ਹੈ, ਸਾਡੀ ਮਦਦ ਕਰੋ help.getConfig. ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ 5 ਐਂਟਰੀਆਂ ਸਨ, ਪਰ 2018 ਦੇ ਮਸ਼ਹੂਰ ਸਮਾਗਮਾਂ ਤੋਂ ਬਾਅਦ, ਗਿਣਤੀ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੋਇਆ ਹੈ।

ਹੁਣ ਯਾਦ ਰੱਖੋ ਕਿ ਅਸੀਂ ਸਰਵਰ 'ਤੇ ਅਗਿਆਤ ਰੂਪ ਵਿੱਚ ਇਸ ਪੜਾਅ 'ਤੇ ਆਏ ਹਾਂ। ਕੀ ਸਿਰਫ਼ ਇੱਕ IP ਪਤਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਬਹੁਤ ਮਹਿੰਗਾ ਨਹੀਂ ਹੈ? MTProto ਦੇ ਅਣ-ਇਨਕ੍ਰਿਪਟਡ ਹਿੱਸੇ ਵਿੱਚ, ਇਹ ਅਤੇ ਹੋਰ ਓਪਰੇਸ਼ਨ ਕਿਉਂ ਨਹੀਂ ਕਰਦੇ? ਮੈਂ ਇਤਰਾਜ਼ ਸੁਣਦਾ ਹਾਂ: "ਅਸੀਂ ਇਹ ਕਿਵੇਂ ਯਕੀਨੀ ਬਣਾ ਸਕਦੇ ਹਾਂ ਕਿ ਇਹ RKN ਨਹੀਂ ਹੈ ਜੋ ਝੂਠੇ ਪਤਿਆਂ ਨਾਲ ਜਵਾਬ ਦੇਵੇਗਾ?" ਇਹ ਕਰਨ ਲਈ ਸਾਨੂੰ ਯਾਦ ਹੈ ਕਿ, ਆਮ ਤੌਰ 'ਤੇ, ਅਧਿਕਾਰਤ ਗਾਹਕ RSA ਕੁੰਜੀਆਂ ਏਮਬੇਡ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ, i.e. ਕੀ ਤੁਸੀਂ ਬਸ ਗਾਹਕ ਬਣੋ ਇਹ ਜਾਣਕਾਰੀ. ਅਸਲ ਵਿੱਚ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਬਲਾਕਿੰਗ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨ ਬਾਰੇ ਜਾਣਕਾਰੀ ਲਈ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ, ਜੋ ਕਿ ਗਾਹਕ ਦੂਜੇ ਚੈਨਲਾਂ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ (ਤਰਕ ਨਾਲ, ਇਹ MTProto ਵਿੱਚ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਜੁੜਨਾ ਹੈ)।

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

ਵੈਸੀਲੀ, [10.07.18 14:45] https://core.telegram.org/method/help.getConfig

config#7dae33e0 [...] = Config;
help.getConfig#c4f9186b = Config;

https://core.telegram.org/api/datacenter

config#232d5905 [...] = Config;
help.getConfig#c4f9186b = Config;

ਸਕੀਮ ਵਿੱਚ ਪਹਿਲਾਂ ਦੂਜੇ ਨੰਬਰ 'ਤੇ ਆਉਂਦਾ ਹੈ

tdesktop ਸਕੀਮਾ ਵਿੱਚ ਤੀਜਾ ਮੁੱਲ ਹੈ

ਹਾਂ, ਉਦੋਂ ਤੋਂ, ਬੇਸ਼ਕ, ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ. ਹਾਲਾਂਕਿ ਇਹ ਜਲਦੀ ਹੀ ਦੁਬਾਰਾ ਅਪ੍ਰਸੰਗਿਕ ਹੋ ਸਕਦਾ ਹੈ। ਇੱਕ ਨਵੇਂ ਡਿਵੈਲਪਰ ਨੂੰ ਕਿਵੇਂ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ? ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਜੇ ਤੁਸੀਂ ਆਪਣੀ ਅਰਜ਼ੀ ਰਜਿਸਟਰ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਤੁਹਾਨੂੰ ਸੂਚਿਤ ਕਰਨਗੇ? ਵੈਸੀਲੀ ਨੇ ਅਜਿਹਾ ਕੀਤਾ, ਪਰ ਅਫ਼ਸੋਸ, ਉਨ੍ਹਾਂ ਨੇ ਉਸਨੂੰ ਕੁਝ ਨਹੀਂ ਭੇਜਿਆ (ਦੁਬਾਰਾ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਦੂਜੇ ਭਾਗ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗੇ).

...ਤੁਸੀਂ ਦੇਖਿਆ ਹੈ ਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਤਰ੍ਹਾਂ API ਵਿੱਚ ਚਲੇ ਗਏ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਅਗਲੇ ਪੱਧਰ ਤੱਕ, ਅਤੇ MTProto ਵਿਸ਼ੇ ਵਿੱਚ ਕੁਝ ਖੁੰਝ ਗਿਆ? ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ:

ਵੈਸੀਲੀ, [28.06.18 02:04] ਐਮ.ਐਮ., ਉਹ e2e 'ਤੇ ਕੁਝ ਐਲਗੋਰਿਥਮਾਂ ਰਾਹੀਂ ਰਮਜ ਕਰ ਰਹੇ ਹਨ।

Mtproto ਦੋਵਾਂ ਡੋਮੇਨਾਂ ਲਈ ਐਨਕ੍ਰਿਪਸ਼ਨ ਐਲਗੋਰਿਦਮ ਅਤੇ ਕੁੰਜੀਆਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ, ਨਾਲ ਹੀ ਇੱਕ ਰੈਪਰ ਬਣਤਰ ਦਾ ਇੱਕ ਬਿੱਟ

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

ਉਹ ਕਿਵੇਂ ਮਿਲਾਉਂਦੇ ਹਨ? ਖੈਰ, ਇੱਥੇ PFS ਲਈ ਉਹੀ ਅਸਥਾਈ ਕੁੰਜੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ (ਤਰੀਕੇ ਨਾਲ, ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟੌਪ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ)। ਇਹ ਇੱਕ API ਬੇਨਤੀ ਦੁਆਰਾ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ auth.bindTempAuthKey, i.e. ਚੋਟੀ ਦੇ ਪੱਧਰ ਤੋਂ. ਪਰ ਉਸੇ ਸਮੇਂ ਇਹ ਹੇਠਲੇ ਪੱਧਰ 'ਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਵਿੱਚ ਦਖਲਅੰਦਾਜ਼ੀ ਕਰਦਾ ਹੈ - ਇਸਦੇ ਬਾਅਦ, ਉਦਾਹਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ initConnection ਆਦਿ, ਇਹ ਨਹੀਂ ਹੈ ਸਿਰਫ ਆਮ ਬੇਨਤੀ. ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰਤੀ DC ਸਿਰਫ ਇੱਕ ਅਸਥਾਈ ਕੁੰਜੀ ਹੋ ਸਕਦੀ ਹੈ, ਹਾਲਾਂਕਿ ਖੇਤਰ auth_key_id ਹਰੇਕ ਸੁਨੇਹੇ ਵਿੱਚ ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ ਹਰੇਕ ਸੁਨੇਹੇ ਨੂੰ ਕੁੰਜੀ ਬਦਲਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਕਿ ਸਰਵਰ ਨੂੰ ਕਿਸੇ ਵੀ ਸਮੇਂ ਅਸਥਾਈ ਕੁੰਜੀ ਨੂੰ "ਭੁੱਲਣ" ਦਾ ਅਧਿਕਾਰ ਹੈ - ਦਸਤਾਵੇਜ਼ ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਹੈ ਕਿ ਇਸ ਕੇਸ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ... ਠੀਕ ਹੈ, ਕਿਉਂ ਨਹੀਂ ਹੋ ਸਕਦਾ ਤੁਹਾਡੇ ਕੋਲ ਕਈ ਕੁੰਜੀਆਂ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਭਵਿੱਖ ਦੇ ਲੂਣ ਦੇ ਸੈੱਟ ਨਾਲ, ਅਤੇ?..

MTProto ਥੀਮ ਬਾਰੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਕੁਝ ਹੋਰ ਗੱਲਾਂ ਹਨ।

ਸੁਨੇਹੇ ਸੁਨੇਹੇ, msg_id, msg_seqno, ਪੁਸ਼ਟੀਕਰਨ, ਗਲਤ ਦਿਸ਼ਾ ਵਿੱਚ ਪਿੰਗ ਅਤੇ ਹੋਰ ਮੁਹਾਵਰੇ

ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਬਾਰੇ ਜਾਣਨ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਕਿਉਂਕਿ ਉਹ ਉੱਚ ਪੱਧਰ 'ਤੇ "ਲੀਕ" ਕਰਦੇ ਹਨ, ਅਤੇ API ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਤੁਹਾਨੂੰ ਉਹਨਾਂ ਬਾਰੇ ਸੁਚੇਤ ਹੋਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ. ਮੰਨ ਲਓ ਕਿ ਸਾਨੂੰ msg_key ਵਿੱਚ ਕੋਈ ਦਿਲਚਸਪੀ ਨਹੀਂ ਹੈ; ਹੇਠਲੇ ਪੱਧਰ ਨੇ ਸਾਡੇ ਲਈ ਸਭ ਕੁਝ ਡੀਕ੍ਰਿਪਟ ਕੀਤਾ ਹੈ। ਪਰ ਡੀਕ੍ਰਿਪਟ ਕੀਤੇ ਡੇਟਾ ਦੇ ਅੰਦਰ ਸਾਡੇ ਕੋਲ ਹੇਠਾਂ ਦਿੱਤੇ ਖੇਤਰ ਹਨ (ਡਾਟੇ ਦੀ ਲੰਬਾਈ ਵੀ, ਇਸ ਲਈ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਪੈਡਿੰਗ ਕਿੱਥੇ ਹੈ, ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ):

• ਲੂਣ - int64
• ਸੈਸ਼ਨ_ਆਈਡੀ - int64
• ਸੁਨੇਹਾ_ਆਈਡੀ - int64
• seq_no - int32

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

ਸਰਵਰ ਨੂੰ ਸੈਸ਼ਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡਣ ਅਤੇ ਕਈ ਕਾਰਨਾਂ ਕਰਕੇ ਇਸ ਤਰੀਕੇ ਨਾਲ ਜਵਾਬ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਹੈ। ਅਸਲ ਵਿੱਚ, ਕਲਾਇੰਟ ਸਾਈਡ ਤੋਂ ਇੱਕ MTProto ਸੈਸ਼ਨ ਕੀ ਹੈ? ਇਹ ਦੋ ਨੰਬਰ ਹਨ session_id и seq_no ਇਸ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਸੁਨੇਹੇ। ਖੈਰ, ਅਤੇ ਅੰਡਰਲਾਈੰਗ TCP ਕੁਨੈਕਸ਼ਨ, ਬੇਸ਼ਕ। ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਕਲਾਇੰਟ ਨੂੰ ਅਜੇ ਵੀ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਕਿਵੇਂ ਕਰਨੀਆਂ ਹਨ, ਉਸਨੇ ਡਿਸਕਨੈਕਟ ਕੀਤਾ ਅਤੇ ਦੁਬਾਰਾ ਕਨੈਕਟ ਕੀਤਾ। ਜੇ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਰਿਆ - ਨਵੇਂ ਟੀਸੀਪੀ ਕੁਨੈਕਸ਼ਨ ਵਿੱਚ ਪੁਰਾਣਾ ਸੈਸ਼ਨ ਜਾਰੀ ਰਿਹਾ, ਵਾਧਾ seq_no ਅੱਗੇ. ਜੇ ਇਸ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਇਸਨੂੰ ਮਿਟਾ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸਦੇ ਪਾਸੇ ਇਹ ਇੱਕ ਕਤਾਰ ਵੀ ਹੈ, ਜਿਵੇਂ ਕਿ ਸਾਨੂੰ ਪਤਾ ਲੱਗਿਆ ਹੈ।

ਇਹ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ seq_no? ਓਹ, ਇਹ ਇੱਕ ਗੁੰਝਲਦਾਰ ਸਵਾਲ ਹੈ. ਇਮਾਨਦਾਰੀ ਨਾਲ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਕੀ ਮਤਲਬ ਸੀ:

ਸਮੱਗਰੀ-ਸਬੰਧਤ ਸੁਨੇਹਾ

ਇੱਕ ਸੁਨੇਹੇ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਪ੍ਰਵਾਨਗੀ ਦੀ ਲੋੜ ਹੈ। ਇਹਨਾਂ ਵਿੱਚ ਸਾਰੇ ਉਪਭੋਗਤਾ ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਸੇਵਾ ਸੁਨੇਹੇ ਸ਼ਾਮਲ ਹਨ, ਲਗਭਗ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਅਤੇ ਮਾਨਤਾਵਾਂ ਨੂੰ ਛੱਡ ਕੇ।

ਸੁਨੇਹਾ ਕ੍ਰਮ ਨੰਬਰ (msg_seqno)

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

1 ਦੇ ਵਾਧੇ ਨਾਲ ਇਹ ਕਿਸ ਕਿਸਮ ਦਾ ਸਰਕਸ ਹੈ, ਅਤੇ ਫਿਰ 2 ਦੁਆਰਾ ਇੱਕ ਹੋਰ?... ਮੈਨੂੰ ਸ਼ੱਕ ਹੈ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਉਹਨਾਂ ਦਾ ਮਤਲਬ ਸੀ "ACK ਲਈ ਸਭ ਤੋਂ ਘੱਟ ਮਹੱਤਵਪੂਰਨ ਬਿੱਟ, ਬਾਕੀ ਇੱਕ ਨੰਬਰ ਹੈ", ਪਰ ਨਤੀਜਾ ਬਿਲਕੁਲ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਹੈ - ਖਾਸ ਤੌਰ 'ਤੇ, ਇਹ ਬਾਹਰ ਆਉਂਦਾ ਹੈ, ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ ਕਈ ਸਮਾਨ ਹੋਣ ਦੀ ਪੁਸ਼ਟੀ seq_no! ਕਿਵੇਂ? ਖੈਰ, ਉਦਾਹਰਨ ਲਈ, ਸਰਵਰ ਸਾਨੂੰ ਕੁਝ ਭੇਜਦਾ ਹੈ, ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਅਸੀਂ ਖੁਦ ਚੁੱਪ ਰਹਿੰਦੇ ਹਾਂ, ਸਿਰਫ ਸੇਵਾ ਸੁਨੇਹਿਆਂ ਨਾਲ ਜਵਾਬ ਦਿੰਦੇ ਹੋਏ ਇਸਦੇ ਸੰਦੇਸ਼ਾਂ ਦੀ ਪ੍ਰਾਪਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਡੀਆਂ ਆਊਟਗੋਇੰਗ ਪੁਸ਼ਟੀਆਂ ਵਿੱਚ ਉਹੀ ਆਊਟਗੋਇੰਗ ਨੰਬਰ ਹੋਵੇਗਾ। ਜੇਕਰ ਤੁਸੀਂ TCP ਤੋਂ ਜਾਣੂ ਹੋ ਅਤੇ ਸੋਚਦੇ ਹੋ ਕਿ ਇਹ ਕਿਸੇ ਤਰ੍ਹਾਂ ਜੰਗਲੀ ਲੱਗਦਾ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਜੰਗਲੀ ਨਹੀਂ ਲੱਗਦਾ, ਕਿਉਂਕਿ TCP ਵਿੱਚ seq_no ਬਦਲਦਾ ਨਹੀਂ ਹੈ, ਪਰ ਪੁਸ਼ਟੀ ਨੂੰ ਜਾਂਦਾ ਹੈ seq_no ਦੂਜੇ ਪਾਸੇ, ਮੈਂ ਤੁਹਾਨੂੰ ਪਰੇਸ਼ਾਨ ਕਰਨ ਲਈ ਜਲਦੀ ਕਰਾਂਗਾ। ਪੁਸ਼ਟੀਕਰਣ MTProto ਵਿੱਚ ਪ੍ਰਦਾਨ ਕੀਤੇ ਗਏ ਹਨ ਨਹੀਂ 'ਤੇ seq_no, ਜਿਵੇਂ ਕਿ TCP ਵਿੱਚ, ਪਰ ਦੁਆਰਾ msg_id !

ਇਹ ਕੀ ਹੈ msg_id, ਇਹਨਾਂ ਖੇਤਰਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ? ਇੱਕ ਵਿਲੱਖਣ ਸੁਨੇਹਾ ਪਛਾਣਕਰਤਾ, ਜਿਵੇਂ ਕਿ ਨਾਮ ਸੁਝਾਅ ਦਿੰਦਾ ਹੈ। ਇਸਨੂੰ 64-ਬਿੱਟ ਨੰਬਰ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਦੇ ਸਭ ਤੋਂ ਹੇਠਲੇ ਬਿੱਟਾਂ ਵਿੱਚ ਦੁਬਾਰਾ "ਸਰਵਰ-ਨਾ-ਸਰਵਰ" ਦਾ ਜਾਦੂ ਹੈ, ਅਤੇ ਬਾਕੀ ਇੱਕ ਯੂਨਿਕਸ ਟਾਈਮਸਟੈਂਪ ਹੈ, ਜਿਸ ਵਿੱਚ ਫਰੈਕਸ਼ਨਲ ਹਿੱਸੇ ਸਮੇਤ, 32 ਬਿੱਟਾਂ ਨੂੰ ਖੱਬੇ ਪਾਸੇ ਸ਼ਿਫਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਉਹ. ਟਾਈਮਸਟੈਂਪ ਪ੍ਰਤੀ ਸੇ (ਅਤੇ ਸਮੇਂ ਵਾਲੇ ਸੁਨੇਹੇ ਜੋ ਬਹੁਤ ਜ਼ਿਆਦਾ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ ਸਰਵਰ ਦੁਆਰਾ ਰੱਦ ਕਰ ਦਿੱਤੇ ਜਾਣਗੇ)। ਇਸ ਤੋਂ ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਇੱਕ ਪਛਾਣਕਰਤਾ ਹੈ ਜੋ ਗਾਹਕ ਲਈ ਗਲੋਬਲ ਹੈ. ਦਿੱਤਾ ਜੋ – ਯਾਦ ਕਰੀਏ session_id - ਸਾਨੂੰ ਗਰੰਟੀ ਹੈ: ਕਿਸੇ ਵੀ ਸਥਿਤੀ ਵਿੱਚ ਇੱਕ ਸੈਸ਼ਨ ਲਈ ਸੰਦੇਸ਼ ਨੂੰ ਵੱਖਰੇ ਸੈਸ਼ਨ ਵਿੱਚ ਨਹੀਂ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਭਾਵ, ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਪਹਿਲਾਂ ਹੀ ਹੈ ਤਿੰਨ ਪੱਧਰ - ਸੈਸ਼ਨ, ਸੈਸ਼ਨ ਨੰਬਰ, ਸੁਨੇਹਾ ਆਈ.ਡੀ. ਇੰਨੀ ਜ਼ਿਆਦਾ ਪੇਚੀਦਗੀ ਕਿਉਂ, ਇਹ ਰਹੱਸ ਬਹੁਤ ਮਹਾਨ ਹੈ।

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, msg_id ਲਈ ਲੋੜੀਂਦਾ...

RPC: ਬੇਨਤੀਆਂ, ਜਵਾਬ, ਤਰੁੱਟੀਆਂ। ਪੁਸ਼ਟੀਕਰਨ।

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖਿਆ ਹੋਵੇਗਾ, ਚਿੱਤਰ ਵਿੱਚ ਕਿਤੇ ਵੀ ਕੋਈ ਖਾਸ "ਇੱਕ RPC ਬੇਨਤੀ ਕਰੋ" ਕਿਸਮ ਜਾਂ ਫੰਕਸ਼ਨ ਨਹੀਂ ਹੈ, ਹਾਲਾਂਕਿ ਜਵਾਬ ਹਨ। ਆਖ਼ਰਕਾਰ, ਸਾਡੇ ਕੋਲ ਸਮੱਗਰੀ ਨਾਲ ਸਬੰਧਤ ਸੁਨੇਹੇ ਹਨ! ਜੋ ਕਿ ਹੈ, ਕੋਈ ਵੀ ਸੁਨੇਹਾ ਇੱਕ ਬੇਨਤੀ ਹੋ ਸਕਦਾ ਹੈ! ਜਾਂ ਨਹੀਂ ਹੋਣਾ। ਇਸ ਸਭ ਤੋਂ ਬਾਦ, ਹਰ ਇਕ ਹੈ msg_id. ਪਰ ਜਵਾਬ ਹਨ:

rpc_result#f35c6d01 req_msg_id:long result:Object = RpcResult;

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

ਹਾਂ?.. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਸੋਚਦੇ ਹੋ? ਆਖ਼ਰਕਾਰ, RPC ਜਵਾਬ ਦਾ ਵੀ ਇੱਕ ਖੇਤਰ ਹੈ msg_id! ਕੀ ਸਾਨੂੰ ਸਰਵਰ 'ਤੇ ਚੀਕਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ "ਤੁਸੀਂ ਮੇਰੇ ਜਵਾਬ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਰਹੇ ਹੋ!"? ਅਤੇ ਹਾਂ, ਪੁਸ਼ਟੀਕਰਨ ਬਾਰੇ ਕੀ ਸੀ? ਪੰਨੇ ਬਾਰੇ ਸੁਨੇਹਿਆਂ ਬਾਰੇ ਸੁਨੇਹੇ ਸਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਹੈ

msgs_ack#62d6b459 msg_ids:Vector long = MsgsAck;

ਅਤੇ ਇਹ ਹਰ ਪਾਸੇ ਦੁਆਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ. ਪਰ ਹਮੇਸ਼ਾ ਨਹੀਂ! ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ RpcResult ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ, ਤਾਂ ਇਹ ਆਪਣੇ ਆਪ ਇੱਕ ਪੁਸ਼ਟੀ ਦੇ ਤੌਰ ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਭਾਵ, ਸਰਵਰ ਤੁਹਾਡੀ ਬੇਨਤੀ ਦਾ MsgsAck ਨਾਲ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ - ਜਿਵੇਂ, "ਮੈਨੂੰ ਇਹ ਪ੍ਰਾਪਤ ਹੋਇਆ।" RpcResult ਤੁਰੰਤ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ। ਇਹ ਦੋਵੇਂ ਹੋ ਸਕਦੇ ਹਨ।

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

ਇਸ ਦੌਰਾਨ, ਆਉ ਸੰਭਾਵਿਤ ਪੁੱਛਗਿੱਛ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਤਰੁਟੀਆਂ ਨੂੰ ਵੇਖੀਏ।

rpc_error#2144ca19 error_code:int error_message:string = RpcError;

ਓਹ, ਕੋਈ ਕਹੇਗਾ, ਇੱਥੇ ਇੱਕ ਹੋਰ ਮਨੁੱਖੀ ਫਾਰਮੈਟ ਹੈ - ਇੱਕ ਲਾਈਨ ਹੈ! ਆਪਣਾ ਸਮਾਂ ਲੈ ਲਓ. ਇਥੇ ਗਲਤੀਆਂ ਦੀ ਸੂਚੀ, ਪਰ ਬੇਸ਼ੱਕ ਪੂਰਾ ਨਹੀਂ। ਇਸ ਤੋਂ ਅਸੀਂ ਸਿੱਖਦੇ ਹਾਂ ਕਿ ਕੋਡ ਹੈ ਕੁਝ ਅਜਿਹਾ HTTP ਗਲਤੀਆਂ (ਠੀਕ ਹੈ, ਬੇਸ਼ੱਕ, ਜਵਾਬਾਂ ਦੇ ਅਰਥ ਵਿਗਿਆਨ ਦਾ ਸਤਿਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ, ਕੁਝ ਸਥਾਨਾਂ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਕੋਡਾਂ ਵਿੱਚ ਬੇਤਰਤੀਬ ਨਾਲ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ), ਅਤੇ ਲਾਈਨ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ CAPITAL_LETTERS_AND_NUMBERS. ਉਦਾਹਰਨ ਲਈ, PHONE_NUMBER_OCCUPIED ਜਾਂ FILE_PART_Х_MISSING। ਖੈਰ, ਇਹ ਹੈ, ਤੁਹਾਨੂੰ ਅਜੇ ਵੀ ਇਸ ਲਾਈਨ ਦੀ ਜ਼ਰੂਰਤ ਹੋਏਗੀ ਪਾਰਸ. ਉਦਾਹਰਨ ਲਈ, FLOOD_WAIT_3600 ਇਸਦਾ ਮਤਲਬ ਹੋਵੇਗਾ ਕਿ ਤੁਹਾਨੂੰ ਇੱਕ ਘੰਟਾ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ, ਅਤੇ PHONE_MIGRATE_5, ਕਿ ਇਸ ਅਗੇਤਰ ਵਾਲਾ ਇੱਕ ਟੈਲੀਫੋਨ ਨੰਬਰ 5ਵੇਂ DC ਵਿੱਚ ਰਜਿਸਟਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਸਾਡੇ ਕੋਲ ਇੱਕ ਕਿਸਮ ਦੀ ਭਾਸ਼ਾ ਹੈ, ਠੀਕ ਹੈ? ਸਾਨੂੰ ਇੱਕ ਸਤਰ ਤੋਂ ਇੱਕ ਦਲੀਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਨਿਯਮਤ ਲੋਕ ਕਰਨਗੇ, ਠੀਕ ਹੈ।

ਦੁਬਾਰਾ ਫਿਰ, ਇਹ ਸੇਵਾ ਸੁਨੇਹੇ ਪੰਨੇ 'ਤੇ ਨਹੀਂ ਹੈ, ਪਰ, ਜਿਵੇਂ ਕਿ ਇਸ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਪਹਿਲਾਂ ਹੀ ਆਮ ਹੈ, ਜਾਣਕਾਰੀ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ ਕਿਸੇ ਹੋਰ ਦਸਤਾਵੇਜ਼ ਪੰਨੇ 'ਤੇ. ਜਾਂ ਸ਼ੱਕ ਪੈਦਾ ਕਰੋ. ਪਹਿਲਾਂ, ਦੇਖੋ, ਟਾਈਪਿੰਗ/ਲੇਅਰ ਉਲੰਘਣਾ - RpcError ਵਿੱਚ ਆਲ੍ਹਣਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ RpcResult. ਬਾਹਰ ਕਿਉਂ ਨਹੀਂ? ਅਸੀਂ ਕੀ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਿਆ?... ਇਸ ਅਨੁਸਾਰ, ਇਸਦੀ ਗਾਰੰਟੀ ਕਿੱਥੇ ਹੈ RpcError ਵਿੱਚ ਏਮਬੇਡ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ RpcResult, ਪਰ ਕਿਸੇ ਹੋਰ ਕਿਸਮ ਵਿੱਚ ਸਿੱਧੇ ਜਾਂ ਨੇਸਟਡ ਹੋ?... ਅਤੇ ਜੇਕਰ ਇਹ ਨਹੀਂ ਹੋ ਸਕਦਾ, ਤਾਂ ਇਹ ਉੱਚ ਪੱਧਰ 'ਤੇ ਕਿਉਂ ਨਹੀਂ ਹੈ, ਜਿਵੇਂ ਕਿ ਇਹ ਗੁੰਮ ਹੈ req_msg_id ? ..

ਪਰ ਆਓ ਸੇਵਾ ਸੁਨੇਹਿਆਂ ਬਾਰੇ ਜਾਰੀ ਰੱਖੀਏ। ਕਲਾਇੰਟ ਇਹ ਸੋਚ ਸਕਦਾ ਹੈ ਕਿ ਸਰਵਰ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਸੋਚ ਰਿਹਾ ਹੈ ਅਤੇ ਇਹ ਸ਼ਾਨਦਾਰ ਬੇਨਤੀ ਕਰ ਸਕਦਾ ਹੈ:

rpc_drop_answer#58e4a740 req_msg_id:long = RpcDropAnswer;

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

ਨਸ਼ਾਖੋਰੀ: ਸੁਨੇਹਾ ਸਥਿਤੀਆਂ

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

ਇਹ ਨਿਰਦੋਸ਼ ਤੌਰ 'ਤੇ, ਪੁਸ਼ਟੀਕਰਨ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਅੱਗੇ ਉਹ ਸਾਨੂੰ ਇਸ ਬਾਰੇ ਦੱਸਦੇ ਹਨ

bad_msg_notification#a7eff811 bad_msg_id:long bad_msg_seqno:int error_code:int = BadMsgNotification;
bad_server_salt#edab447b bad_msg_id:long bad_msg_seqno:int error_code:int new_server_salt:long = BadMsgNotification;

ਖੈਰ, ਹਰ ਕੋਈ ਜੋ ਐਮਟੀਪ੍ਰੋਟੋ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਉਹਨਾਂ ਨਾਲ ਨਜਿੱਠਣਾ ਪਏਗਾ; "ਸਹੀ - ਮੁੜ-ਕੰਪਾਈਲਡ - ਲਾਂਚ" ਚੱਕਰ ਵਿੱਚ, ਸੰਪਾਦਨਾਂ ਦੌਰਾਨ ਖਰਾਬ ਹੋਣ ਵਿੱਚ ਕਾਮਯਾਬ ਹੋਏ ਨੰਬਰ ਦੀਆਂ ਗਲਤੀਆਂ ਜਾਂ ਲੂਣ ਪ੍ਰਾਪਤ ਕਰਨਾ ਇੱਕ ਆਮ ਗੱਲ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਥੇ ਦੋ ਨੁਕਤੇ ਹਨ:

1. ਇਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਸਲੀ ਸੁਨੇਹਾ ਖਤਮ ਹੋ ਗਿਆ ਹੈ. ਸਾਨੂੰ ਕੁਝ ਕਤਾਰਾਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ, ਅਸੀਂ ਇਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਦੇਖਾਂਗੇ।
2. ਇਹ ਅਜੀਬ ਗਲਤੀ ਨੰਬਰ ਕੀ ਹਨ? 16, 17, 18, 19, 20, 32, 33, 34, 35, 48, 64... ਹੋਰ ਨੰਬਰ ਕਿੱਥੇ ਹਨ, ਟੌਮੀ?

ਦਸਤਾਵੇਜ਼ ਦੱਸਦਾ ਹੈ:

ਇਰਾਦਾ ਇਹ ਹੈ ਕਿ error_code ਮੁੱਲਾਂ ਨੂੰ ਸਮੂਹਬੱਧ ਕੀਤਾ ਗਿਆ ਹੈ (error_code >> 4): ਉਦਾਹਰਨ ਲਈ, ਕੋਡ 0x40 — 0x4f ਕੰਟੇਨਰ ਸੜਨ ਵਿੱਚ ਤਰੁੱਟੀਆਂ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

ਪਰ, ਪਹਿਲਾਂ, ਦੂਜੀ ਦਿਸ਼ਾ ਵਿੱਚ ਇੱਕ ਸ਼ਿਫਟ, ਅਤੇ ਦੂਜਾ, ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ, ਹੋਰ ਕੋਡ ਕਿੱਥੇ ਹਨ? ਲੇਖਕ ਦੇ ਸਿਰ ਵਿੱਚ?... ਹਾਲਾਂਕਿ, ਇਹ ਮਾਮੂਲੀ ਹਨ.

ਸੁਨੇਹਾ ਸਥਿਤੀਆਂ ਅਤੇ ਸੰਦੇਸ਼ ਦੀਆਂ ਕਾਪੀਆਂ ਬਾਰੇ ਸੁਨੇਹਿਆਂ ਵਿੱਚ ਨਸ਼ਾ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ:

• ਸੁਨੇਹਾ ਸਥਿਤੀ ਜਾਣਕਾਰੀ ਲਈ ਬੇਨਤੀ
  ਜੇਕਰ ਕਿਸੇ ਵੀ ਧਿਰ ਨੇ ਕੁਝ ਸਮੇਂ ਲਈ ਆਪਣੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਸੁਨੇਹਿਆਂ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤੀ ਹੈ, ਤਾਂ ਇਹ ਦੂਜੀ ਧਿਰ ਤੋਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਬੇਨਤੀ ਕਰ ਸਕਦੀ ਹੈ:
  msgs_state_req#da69fb52 msg_ids:Vector long = MsgsStateReq;
• ਸੁਨੇਹਿਆਂ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਜਾਣਕਾਰੀ ਵਾਲਾ ਸੁਨੇਹਾ
  msgs_state_info#04deb57d req_msg_id:long info:string = MsgsStateInfo;
  ਇਥੇ, info ਇੱਕ ਸਤਰ ਹੈ ਜਿਸ ਵਿੱਚ ਆਉਣ ਵਾਲੀ msg_ids ਸੂਚੀ ਵਿੱਚੋਂ ਹਰੇਕ ਸੁਨੇਹੇ ਲਈ ਸੁਨੇਹਾ ਸਥਿਤੀ ਦਾ ਬਿਲਕੁਲ ਇੱਕ ਬਾਈਟ ਹੁੰਦਾ ਹੈ:
  • 1 = ਸੁਨੇਹੇ ਬਾਰੇ ਕੁਝ ਵੀ ਪਤਾ ਨਹੀਂ ਹੈ (msg_id ਬਹੁਤ ਘੱਟ ਹੈ, ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਦੂਜੀ ਧਿਰ ਇਸਨੂੰ ਭੁੱਲ ਗਈ ਹੋਵੇ)
  • 2 = ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਇਆ (msg_id ਸਟੋਰ ਕੀਤੇ ਪਛਾਣਕਰਤਾਵਾਂ ਦੀ ਸੀਮਾ ਦੇ ਅੰਦਰ ਆਉਂਦਾ ਹੈ; ਹਾਲਾਂਕਿ, ਦੂਜੀ ਧਿਰ ਨੂੰ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਅਜਿਹਾ ਸੁਨੇਹਾ ਨਹੀਂ ਮਿਲਿਆ ਹੈ)
  • 3 = ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਹੋਇਆ (msg_id ਬਹੁਤ ਜ਼ਿਆਦਾ; ਹਾਲਾਂਕਿ, ਦੂਜੀ ਧਿਰ ਨੇ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਅਜੇ ਤੱਕ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਹੈ)
  • 4 = ਸੁਨੇਹਾ ਪ੍ਰਾਪਤ ਹੋਇਆ (ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਜਵਾਬ ਉਸੇ ਸਮੇਂ ਇੱਕ ਰਸੀਦ ਰਸੀਦ ਵੀ ਹੈ)
  • +8 = ਸੁਨੇਹਾ ਪਹਿਲਾਂ ਹੀ ਸਵੀਕਾਰ ਕੀਤਾ ਗਿਆ ਹੈ
  • +16 = ਸੁਨੇਹਾ ਜਿਸ ਲਈ ਰਸੀਦ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ
  • +32 = ਸੁਨੇਹੇ ਵਿੱਚ ਮੌਜੂਦ RPC ਪੁੱਛਗਿੱਛ ਜਾਂ ਪ੍ਰਕਿਰਿਆ ਪਹਿਲਾਂ ਹੀ ਮੁਕੰਮਲ ਹੋ ਗਈ ਹੈ
  • +64 = ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੀਤੇ ਸੁਨੇਹੇ ਲਈ ਸਮੱਗਰੀ-ਸਬੰਧਤ ਜਵਾਬ
  • +128 = ਦੂਜੀ ਧਿਰ ਇਸ ਤੱਥ ਲਈ ਜਾਣਦੀ ਹੈ ਕਿ ਸੁਨੇਹਾ ਪਹਿਲਾਂ ਹੀ ਪ੍ਰਾਪਤ ਹੋ ਚੁੱਕਾ ਹੈ
    ਇਸ ਜਵਾਬ ਲਈ ਇੱਕ ਰਸੀਦ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਸੰਬੰਧਿਤ msgs_state_req ਦੀ ਇੱਕ ਰਸੀਦ ਹੈ, ਆਪਣੇ ਆਪ ਵਿੱਚ।
    ਨੋਟ ਕਰੋ ਕਿ ਜੇਕਰ ਇਹ ਅਚਾਨਕ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ ਦੂਜੀ ਧਿਰ ਕੋਲ ਕੋਈ ਸੁਨੇਹਾ ਨਹੀਂ ਹੈ ਜੋ ਲੱਗਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਭੇਜਿਆ ਗਿਆ ਹੈ, ਤਾਂ ਸੁਨੇਹਾ ਸਿਰਫ਼ ਦੁਬਾਰਾ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਭਾਵੇਂ ਦੂਜੀ ਧਿਰ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਸੁਨੇਹੇ ਦੀਆਂ ਦੋ ਕਾਪੀਆਂ ਪ੍ਰਾਪਤ ਹੋਣ, ਡੁਪਲੀਕੇਟ ਨੂੰ ਅਣਡਿੱਠ ਕੀਤਾ ਜਾਵੇਗਾ। (ਜੇਕਰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੰਘ ਗਿਆ ਹੈ, ਅਤੇ ਅਸਲੀ msg_id ਹੁਣ ਵੈਧ ਨਹੀਂ ਹੈ, ਤਾਂ ਸੁਨੇਹਾ msg_copy ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਣਾ ਹੈ)।
• ਸੁਨੇਹਿਆਂ ਦੀ ਸਥਿਤੀ ਦਾ ਸਵੈ-ਇੱਛਤ ਸੰਚਾਰ
  ਕੋਈ ਵੀ ਧਿਰ ਆਪਣੀ ਮਰਜ਼ੀ ਨਾਲ ਦੂਜੀ ਧਿਰ ਦੁਆਰਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤੇ ਸੰਦੇਸ਼ਾਂ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਦੂਜੀ ਧਿਰ ਨੂੰ ਸੂਚਿਤ ਕਰ ਸਕਦੀ ਹੈ।
  msgs_all_info#8cc0d131 msg_ids:Vector long info:string = MsgsAllInfo
• ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਸਥਿਤੀ ਦਾ ਵਿਸਤ੍ਰਿਤ ਸਵੈ-ਇੱਛਤ ਸੰਚਾਰ
  ...
  msg_detailed_info#276d3ec6 msg_id:long answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
msg_new_detailed_info#809db6df answer_msg_id:long bytes:int status:int = MsgDetailedInfo;
• ਸੁਨੇਹੇ ਮੁੜ-ਭੇਜਣ ਲਈ ਸਪਸ਼ਟ ਬੇਨਤੀ
  msg_resend_req#7d861a08 msg_ids:Vector long = MsgResendReq;
  ਰਿਮੋਟ ਪਾਰਟੀ ਤੁਰੰਤ ਬੇਨਤੀ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ ਦੁਬਾਰਾ ਭੇਜ ਕੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ […]
• ਜਵਾਬ ਮੁੜ-ਭੇਜਣ ਲਈ ਸਪੱਸ਼ਟ ਬੇਨਤੀ
  msg_resend_ans_req#8610baeb msg_ids:Vector long = MsgResendReq;
  ਰਿਮੋਟ ਪਾਰਟੀ ਤੁਰੰਤ ਦੁਬਾਰਾ ਭੇਜ ਕੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਵਾਬ ਬੇਨਤੀ ਕੀਤੇ ਸੁਨੇਹਿਆਂ ਨੂੰ […]
• ਸੁਨੇਹੇ ਦੀਆਂ ਕਾਪੀਆਂ
  ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਇੱਕ msg_id ਵਾਲਾ ਇੱਕ ਪੁਰਾਣਾ ਸੁਨੇਹਾ ਜੋ ਹੁਣ ਵੈਧ ਨਹੀਂ ਹੈ, ਨੂੰ ਦੁਬਾਰਾ ਭੇਜਣ ਦੀ ਲੋੜ ਹੈ। ਫਿਰ, ਇਸਨੂੰ ਇੱਕ ਕਾਪੀ ਕੰਟੇਨਰ ਵਿੱਚ ਲਪੇਟਿਆ ਜਾਂਦਾ ਹੈ:
  msg_copy#e06046b2 orig_message:Message = MessageCopy;
  ਇੱਕ ਵਾਰ ਪ੍ਰਾਪਤ ਹੋਣ 'ਤੇ, ਸੰਦੇਸ਼ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਸੰਸਾਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਰੈਪਰ ਉੱਥੇ ਨਹੀਂ ਸੀ। ਹਾਲਾਂਕਿ, ਜੇਕਰ ਇਹ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਸੁਨੇਹਾ orig_message.msg_id ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਨਵੇਂ ਸੰਦੇਸ਼ 'ਤੇ ਕਾਰਵਾਈ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਜਦੋਂ ਕਿ ਉਸੇ ਸਮੇਂ, ਇਹ ਅਤੇ orig_message.msg_id ਨੂੰ ਸਵੀਕਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)। orig_message.msg_id ਦਾ ਮੁੱਲ ਕੰਟੇਨਰ ਦੇ msg_id ਤੋਂ ਘੱਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਚਲੋ ਵੀ ਕਿਸ ਗੱਲ ਬਾਰੇ ਚੁੱਪ ਰਹੀਏ msgs_state_info ਦੁਬਾਰਾ ਅਧੂਰੇ TL ਦੇ ਕੰਨ ਚਿਪਕ ਰਹੇ ਹਨ (ਸਾਨੂੰ ਬਾਈਟਸ ਦੇ ਇੱਕ ਵੈਕਟਰ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਹੇਠਲੇ ਦੋ ਬਿੱਟਾਂ ਵਿੱਚ ਇੱਕ ਐਨਮ ਸੀ, ਅਤੇ ਉੱਚੇ ਦੋ ਬਿੱਟਾਂ ਵਿੱਚ ਫਲੈਗ ਸਨ)। ਗੱਲ ਵੱਖਰੀ ਹੈ। ਕੀ ਕੋਈ ਸਮਝਦਾ ਹੈ ਕਿ ਇਹ ਸਭ ਅਮਲ ਵਿਚ ਕਿਉਂ ਹੈ? ਇੱਕ ਅਸਲੀ ਗਾਹਕ ਵਿੱਚ ਜ਼ਰੂਰੀ?... ਮੁਸ਼ਕਲ ਨਾਲ, ਪਰ ਕੋਈ ਵਿਅਕਤੀ ਕੁਝ ਲਾਭ ਦੀ ਕਲਪਨਾ ਕਰ ਸਕਦਾ ਹੈ ਜੇਕਰ ਕੋਈ ਵਿਅਕਤੀ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਹੈ, ਅਤੇ ਇੱਕ ਇੰਟਰਐਕਟਿਵ ਮੋਡ ਵਿੱਚ - ਸਰਵਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਕੀ ਅਤੇ ਕਿਵੇਂ. ਪਰ ਇੱਥੇ ਬੇਨਤੀਆਂ ਦਾ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ ਸੈਰ.

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

ਪਿੰਗ ਅਤੇ ਸਮਾਂ। ਕਤਾਰਾਂ।

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

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

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

ਖੈਰ, ਇਹ ਹੈ, ਤੁਸੀਂ ਸਮਝਦੇ ਹੋ, ਠੀਕ ਹੈ? ਜੇਕਰ ਤੁਹਾਨੂੰ TCP ਉੱਤੇ ਚੱਲ ਰਹੇ ਪ੍ਰੋਟੋਕੋਲ ਦੇ ਸਿਖਰ 'ਤੇ TCP ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਨਾ ਹੈ, ਤਾਂ ਇਹ ਇੱਕ ਬਹੁਤ ਹੀ ਮਾੜੇ ਢੰਗ ਨਾਲ ਡਿਜ਼ਾਈਨ ਕੀਤੇ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

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

1. ਇਹ ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਹੈ ਅਤੇ ਏਨਕ੍ਰਿਪਸ਼ਨ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ।
2. ਨਿਯੁਕਤ ਕੀਤਾ ਗਿਆ msg_id ਅਤੇ ਸੁਨੇਹਾ ਇੱਕ ਹੋਰ ਕਤਾਰ ਵਿੱਚ ਚਲਾ ਗਿਆ - ਸੰਭਵ ਫਾਰਵਰਡਿੰਗ; ਸਾਕਟ ਨੂੰ ਭੇਜੋ.
3. a) ਸਰਵਰ ਨੇ MsgsAck ਦਾ ਜਵਾਬ ਦਿੱਤਾ - ਸੁਨੇਹਾ ਡਿਲੀਵਰ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਸੀਂ ਇਸਨੂੰ "ਹੋਰ ਕਤਾਰ" ਤੋਂ ਮਿਟਾ ਦਿੰਦੇ ਹਾਂ।
   b) ਜਾਂ ਇਸਦੇ ਉਲਟ, ਉਸਨੂੰ ਕੁਝ ਪਸੰਦ ਨਹੀਂ ਆਇਆ, ਉਸਨੇ badmsg ਦਾ ਜਵਾਬ ਦਿੱਤਾ - "ਇੱਕ ਹੋਰ ਕਤਾਰ" ਤੋਂ ਦੁਬਾਰਾ ਭੇਜੋ
   c) ਕੁਝ ਵੀ ਪਤਾ ਨਹੀਂ ਹੈ, ਸੰਦੇਸ਼ ਨੂੰ ਕਿਸੇ ਹੋਰ ਕਤਾਰ ਤੋਂ ਭੇਜਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ - ਪਰ ਇਹ ਬਿਲਕੁਲ ਪਤਾ ਨਹੀਂ ਹੈ ਕਿ ਕਦੋਂ.
4. ਸਰਵਰ ਨੇ ਅੰਤ ਵਿੱਚ ਜਵਾਬ ਦਿੱਤਾ RpcResult - ਅਸਲ ਜਵਾਬ (ਜਾਂ ਗਲਤੀ) - ਨਾ ਸਿਰਫ਼ ਡਿਲੀਵਰ ਕੀਤਾ ਗਿਆ, ਸਗੋਂ ਪ੍ਰਕਿਰਿਆ ਵੀ ਕੀਤੀ ਗਈ।

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

ਅਤੇ ਇਸ ਸਮੇਂ ਗੈਰ-ਤਕਨੀਕੀ ਵਿਚਾਰ ਖੇਡ ਵਿੱਚ ਆਉਂਦੇ ਹਨ. ਤਜਰਬੇ ਤੋਂ, ਅਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਬੈਸਾਖੀਆਂ ਦੇਖੀਆਂ ਹਨ, ਅਤੇ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਹੁਣ ਬੁਰੀ ਸਲਾਹ ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਹੋਰ ਉਦਾਹਰਣਾਂ ਦੇਖਾਂਗੇ - ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ, ਕੀ ਇਹ ਭਰੋਸਾ ਕਰਨ ਅਤੇ ਅਜਿਹੇ ਫੈਸਲੇ ਲੈਣ ਦੇ ਯੋਗ ਹੈ? ਸਵਾਲ ਅਲੰਕਾਰਿਕ ਹੈ (ਬਿਲਕੁਲ ਨਹੀਂ)।

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

ਇੱਕ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ RPC ਜਵਾਬ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਇੱਕ ਕਲਾਇੰਟ (ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ RPC ਪੁੱਛਗਿੱਛ) ਤੋਂ ਇੱਕ ਸੰਦੇਸ਼ ਦੀ ਪ੍ਰਾਪਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਇੱਕ ਜਵਾਬ ਆਉਣ ਵਿੱਚ ਲੰਬਾ ਸਮਾਂ ਹੈ, ਤਾਂ ਇੱਕ ਸਰਵਰ ਪਹਿਲਾਂ ਇੱਕ ਰਸੀਦ ਰਸੀਦ ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੁਝ ਹੱਦ ਤੱਕ ਬਾਅਦ ਵਿੱਚ, RPC ਜਵਾਬ ਖੁਦ ਭੇਜ ਸਕਦਾ ਹੈ।

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

... ਮੈਂ ਅਨੁਵਾਦ ਕਰਦਾ ਹਾਂ: ਅਸੀਂ ਖੁਦ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਸਾਨੂੰ ਇਸਦੀ ਕਿੰਨੀ ਅਤੇ ਕਿਵੇਂ ਲੋੜ ਹੈ, ਇਸ ਲਈ ਮੰਨ ਲਓ ਕਿ ਇਸਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਹੋਣ ਦਿਓ।

ਅਤੇ ਪਿੰਗਾਂ ਬਾਰੇ:

ਪਿੰਗ ਸੁਨੇਹੇ (ਪਿੰਗ/ਪੋਂਗ)

ping#7abe77ec ping_id:long = Pong;

ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ ਉਸੇ ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਵਾਪਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

pong#347773c5 msg_id:long ping_id:long = Pong;

ਇਹਨਾਂ ਸੁਨੇਹਿਆਂ ਲਈ ਰਸੀਦ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇੱਕ ਪੌਂਗ ਕੇਵਲ ਇੱਕ ਪਿੰਗ ਦੇ ਜਵਾਬ ਵਿੱਚ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਇੱਕ ਪਿੰਗ ਨੂੰ ਕਿਸੇ ਵੀ ਪਾਸੇ ਤੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਸਥਗਤ ਕਨੈਕਸ਼ਨ ਬੰਦ + ਪਿੰਗ

ping_delay_disconnect#f3427b8c ping_id:long disconnect_delay:int = Pong;

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

ਕੀ ਤੁਸੀਂ ਪਾਗਲ ਹੋ?! 60 ਸਕਿੰਟਾਂ ਵਿੱਚ, ਰੇਲਗੱਡੀ ਸਟੇਸ਼ਨ ਵਿੱਚ ਦਾਖਲ ਹੋ ਜਾਵੇਗੀ, ਉਤਰੇਗੀ ਅਤੇ ਯਾਤਰੀਆਂ ਨੂੰ ਚੁੱਕ ਲਵੇਗੀ, ਅਤੇ ਦੁਬਾਰਾ ਸੁਰੰਗ ਵਿੱਚ ਸੰਪਰਕ ਟੁੱਟ ਜਾਵੇਗਾ। 120 ਸਕਿੰਟਾਂ ਵਿੱਚ, ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਸੁਣਦੇ ਹੋ, ਇਹ ਇੱਕ ਹੋਰ 'ਤੇ ਪਹੁੰਚ ਜਾਵੇਗਾ, ਅਤੇ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਕਨੈਕਸ਼ਨ ਟੁੱਟ ਜਾਵੇਗਾ। ਖੈਰ, ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਲੱਤਾਂ ਕਿੱਥੋਂ ਆ ਰਹੀਆਂ ਹਨ - “ਮੈਂ ਇੱਕ ਘੰਟੀ ਸੁਣੀ, ਪਰ ਇਹ ਨਹੀਂ ਪਤਾ ਕਿ ਇਹ ਕਿੱਥੇ ਹੈ”, ਇੱਥੇ Nagl ਦਾ ਐਲਗੋਰਿਦਮ ਅਤੇ TCP_NODELAY ਵਿਕਲਪ ਹੈ, ਜੋ ਇੰਟਰਐਕਟਿਵ ਕੰਮ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਪਰ, ਮਾਫ ਕਰਨਾ, ਇਸਦੇ ਮੂਲ ਮੁੱਲ - 200 ਨੂੰ ਫੜੀ ਰੱਖੋ ਮਿਲਿਸਕਿੰਟ ਜੇਕਰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਕੁਝ ਅਜਿਹਾ ਹੀ ਦਰਸਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਕੁਝ ਸੰਭਾਵਿਤ ਪੈਕੇਟਾਂ 'ਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ 5 ਸਕਿੰਟਾਂ ਲਈ ਬੰਦ ਕਰ ਦਿਓ, ਜਾਂ ਜੋ ਵੀ "ਉਪਭੋਗਤਾ ਟਾਈਪ ਕਰ ਰਿਹਾ ਹੈ..." ਸੁਨੇਹਾ ਸਮਾਂ ਸਮਾਪਤ ਹੋ ਗਿਆ ਹੈ। ਪਰ ਹੋਰ ਨਹੀਂ।

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਪਿੰਗ. ਯਾਨੀ, TCP ਕੁਨੈਕਸ਼ਨ ਦੀ ਸਜੀਵਤਾ ਦੀ ਜਾਂਚ ਕਰਨਾ। ਇਹ ਮਜ਼ਾਕੀਆ ਹੈ, ਪਰ ਲਗਭਗ 10 ਸਾਲ ਪਹਿਲਾਂ ਮੈਂ ਸਾਡੇ ਫੈਕਲਟੀ ਦੇ ਡੋਰਮ ਦੇ ਮੈਸੇਂਜਰ ਬਾਰੇ ਇੱਕ ਆਲੋਚਨਾਤਮਕ ਟੈਕਸਟ ਲਿਖਿਆ ਸੀ - ਉੱਥੋਂ ਦੇ ਲੇਖਕਾਂ ਨੇ ਕਲਾਇੰਟ ਤੋਂ ਸਰਵਰ ਨੂੰ ਪਿੰਗ ਵੀ ਕੀਤਾ, ਨਾ ਕਿ ਉਲਟ। ਪਰ ਤੀਜੇ ਸਾਲ ਦੇ ਵਿਦਿਆਰਥੀ ਇੱਕ ਚੀਜ਼ ਹਨ, ਅਤੇ ਇੱਕ ਅੰਤਰਰਾਸ਼ਟਰੀ ਦਫਤਰ ਇੱਕ ਹੋਰ ਹੈ, ਠੀਕ? ..

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

ਚੈਟ/IM ਸਿਸਟਮ ਇੱਕ ਵਾਧੂ ਕਾਰਨ ਕਰਕੇ ਦੂਜੇ ਕੇਸ ਵਿੱਚ ਆਉਂਦੇ ਹਨ - ਔਨਲਾਈਨ ਸਥਿਤੀਆਂ। ਜੇ ਉਪਭੋਗਤਾ "ਬੰਦ ਹੋ ਗਿਆ", ਤਾਂ ਤੁਹਾਨੂੰ ਇਸ ਬਾਰੇ ਉਸਦੇ ਵਾਰਤਾਕਾਰਾਂ ਨੂੰ ਸੂਚਿਤ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਨਹੀਂ ਤਾਂ, ਤੁਸੀਂ ਇੱਕ ਗਲਤੀ ਦੇ ਨਾਲ ਖਤਮ ਹੋਵੋਗੇ ਜੋ ਜੈਬਰ ਦੇ ਸਿਰਜਣਹਾਰਾਂ ਨੇ ਕੀਤੀ (ਅਤੇ 20 ਸਾਲਾਂ ਲਈ ਸੁਧਾਰੀ ਗਈ) - ਉਪਭੋਗਤਾ ਨੇ ਡਿਸਕਨੈਕਟ ਕਰ ਦਿੱਤਾ ਹੈ, ਪਰ ਉਹ ਉਸਨੂੰ ਸੰਦੇਸ਼ ਲਿਖਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ, ਇਹ ਵਿਸ਼ਵਾਸ ਕਰਦੇ ਹੋਏ ਕਿ ਉਹ ਔਨਲਾਈਨ ਹੈ (ਜੋ ਇਹਨਾਂ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਗੁਆਚ ਗਏ ਸਨ) ਡਿਸਕਨੈਕਟ ਹੋਣ ਤੋਂ ਕੁਝ ਮਿੰਟ ਪਹਿਲਾਂ)। ਨਹੀਂ, TCP_KEEPALIVE ਵਿਕਲਪ, ਜੋ ਕਿ ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਜੋ ਇਹ ਨਹੀਂ ਸਮਝਦੇ ਹਨ ਕਿ TCP ਟਾਈਮਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ ਬੇਤਰਤੀਬੇ ਤਰੀਕੇ ਨਾਲ ਸੁੱਟੇ ਜਾਂਦੇ ਹਨ (ਜੰਗਲੀ ਮੁੱਲਾਂ ਜਿਵੇਂ ਕਿ ਦਸ ਸਕਿੰਟਾਂ ਦੇ ਸੈੱਟ ਕਰਕੇ), ਇੱਥੇ ਮਦਦ ਨਹੀਂ ਕਰੇਗਾ - ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ ਨਾ ਸਿਰਫ਼ OS ਕਰਨਲ ਉਪਭੋਗਤਾ ਦੀ ਮਸ਼ੀਨ ਜ਼ਿੰਦਾ ਹੈ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੀ ਹੈ, ਜਵਾਬ ਦੇਣ ਦੇ ਯੋਗ ਹੈ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਖੁਦ (ਕੀ ਤੁਹਾਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਫ੍ਰੀਜ਼ ਨਹੀਂ ਹੋ ਸਕਦਾ? ਉਬੰਟੂ 18.04 'ਤੇ ਟੈਲੀਗ੍ਰਾਮ ਡੈਸਕਟੌਪ ਮੇਰੇ ਲਈ ਇੱਕ ਤੋਂ ਵੱਧ ਵਾਰ ਫ੍ਰੀਜ਼ ਹੋਇਆ ਹੈ)।

ਇਸ ਲਈ ਤੁਹਾਨੂੰ ਪਿੰਗ ਕਰਨੀ ਪਵੇਗੀ ਸਰਵਰ ਕਲਾਇੰਟ, ਅਤੇ ਇਸਦੇ ਉਲਟ ਨਹੀਂ - ਜੇਕਰ ਕਲਾਇੰਟ ਅਜਿਹਾ ਕਰਦਾ ਹੈ, ਜੇਕਰ ਕੁਨੈਕਸ਼ਨ ਟੁੱਟ ਗਿਆ ਹੈ, ਪਿੰਗ ਡਿਲੀਵਰ ਨਹੀਂ ਕੀਤੀ ਜਾਵੇਗੀ, ਟੀਚਾ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।

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

ਇਸ ਨੂੰ ਕਿਵੇਂ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ?

ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਉਪਰੋਕਤ ਤੱਥ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਟੈਲੀਗ੍ਰਾਮ/VKontakte ਟੀਮ ਕੰਪਿਊਟਰ ਨੈਟਵਰਕ ਦੇ ਟ੍ਰਾਂਸਪੋਰਟ (ਅਤੇ ਹੇਠਲੇ) ਪੱਧਰ ਅਤੇ ਸੰਬੰਧਿਤ ਮਾਮਲਿਆਂ ਵਿੱਚ ਉਹਨਾਂ ਦੀ ਘੱਟ ਯੋਗਤਾਵਾਂ ਦੇ ਖੇਤਰ ਵਿੱਚ ਬਹੁਤ ਸਮਰੱਥ ਨਹੀਂ ਹੈ।

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

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

1. ਗਾਹਕ ਨੂੰ TCP ਕੁਨੈਕਸ਼ਨ ਰੱਖਣ ਵਾਲਾ ਸਰਵਰ ਜ਼ਿੰਮੇਵਾਰੀ ਲੈਂਦਾ ਹੈ - ਜੇਕਰ ਇਸ ਨੇ ਸਾਕਟ ਤੋਂ ਪੜ੍ਹਿਆ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਕਿਸੇ ਗਲਤੀ ਨੂੰ ਸਵੀਕਾਰ ਕਰੋ, ਪ੍ਰਕਿਰਿਆ ਕਰੋ ਜਾਂ ਵਾਪਸ ਕਰੋ, ਕੋਈ ਨੁਕਸਾਨ ਨਹੀਂ। ਫਿਰ ਪੁਸ਼ਟੀ ਆਈਡੀ ਦਾ ਵੈਕਟਰ ਨਹੀਂ ਹੈ, ਪਰ ਸਿਰਫ਼ "ਆਖਰੀ ਪ੍ਰਾਪਤ ਹੋਈ seq_no" - ਸਿਰਫ਼ ਇੱਕ ਸੰਖਿਆ, ਜਿਵੇਂ ਕਿ TCP (ਦੋ ਨੰਬਰ - ਤੁਹਾਡੀ seq ਅਤੇ ਪੁਸ਼ਟੀ ਕੀਤੀ ਗਈ)। ਅਸੀਂ ਹਮੇਸ਼ਾ ਸੈਸ਼ਨ ਦੇ ਅੰਦਰ ਹੁੰਦੇ ਹਾਂ, ਕੀ ਅਸੀਂ ਨਹੀਂ ਹਾਂ?
2. ਰੀਪਲੇਅ ਹਮਲਿਆਂ ਨੂੰ ਰੋਕਣ ਲਈ ਟਾਈਮਸਟੈਂਪ ਇੱਕ ਵੱਖਰਾ ਖੇਤਰ ਬਣ ਜਾਂਦਾ ਹੈ, ਇੱਕ ਲਾ ਨੋਨਸ। ਇਹ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਕਿਸੇ ਹੋਰ ਚੀਜ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ. ਕਾਫ਼ੀ ਅਤੇ uint32 - ਜੇਕਰ ਸਾਡਾ ਲੂਣ ਘੱਟੋ-ਘੱਟ ਹਰ ਅੱਧੇ ਦਿਨ ਵਿੱਚ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਅਸੀਂ ਮੌਜੂਦਾ ਸਮੇਂ ਦੇ ਇੱਕ ਪੂਰਨ ਅੰਕ ਦੇ ਹੇਠਲੇ-ਕ੍ਰਮ ਵਾਲੇ ਬਿੱਟਾਂ ਨੂੰ 16 ਬਿੱਟ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ, ਬਾਕੀ - ਇੱਕ ਸਕਿੰਟ (ਹੁਣ ਵਾਂਗ) ਦੇ ਇੱਕ ਅੰਸ਼ਿਕ ਹਿੱਸੇ ਲਈ।
3. ਹਟਾਇਆ ਗਿਆ msg_id ਬਿਲਕੁਲ - ਬੈਕਐਂਡ 'ਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਵੱਖ ਕਰਨ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਪਹਿਲਾਂ, ਕਲਾਇੰਟ ਆਈਡੀ ਹੈ, ਅਤੇ ਦੂਜਾ, ਸੈਸ਼ਨ ਆਈਡੀ, ਉਹਨਾਂ ਨੂੰ ਜੋੜਦਾ ਹੈ। ਇਸ ਅਨੁਸਾਰ, ਬੇਨਤੀ ਪਛਾਣਕਰਤਾ ਦੇ ਤੌਰ 'ਤੇ ਸਿਰਫ ਇੱਕ ਚੀਜ਼ ਕਾਫੀ ਹੈ seq_no.

ਇਹ ਸਭ ਤੋਂ ਸਫਲ ਵਿਕਲਪ ਵੀ ਨਹੀਂ ਹੈ; ਇੱਕ ਸੰਪੂਰਨ ਬੇਤਰਤੀਬ ਇੱਕ ਪਛਾਣਕਰਤਾ ਵਜੋਂ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ - ਇਹ ਪਹਿਲਾਂ ਹੀ ਉੱਚ-ਪੱਧਰੀ API ਵਿੱਚ ਇੱਕ ਸੁਨੇਹਾ ਭੇਜਣ ਵੇਲੇ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਵੈਸੇ। ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਸੰਪੂਰਨ ਤੋਂ ਸੰਪੂਰਨ ਤੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੀਮੇਕ ਕਰਨਾ ਬਿਹਤਰ ਹੋਵੇਗਾ, ਪਰ ਇਹ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਲਈ ਵਿਸ਼ਾ ਹੈ, ਨਾ ਕਿ ਇਸ ਪੋਸਟ ਲਈ।

API?

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

ਧਿਆਨ ਦਿਓ, ਹੁਣ ਲੇਖ ਵਿਚ ਪਰਲ ਵਿਚ ਇਕੋ ਇਕ ਉਦਾਹਰਣ ਹੋਵੇਗੀ! (ਉਹਨਾਂ ਲਈ ਜੋ ਸੰਟੈਕਸ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ, ਅਸੀਸ ਦੀ ਪਹਿਲੀ ਦਲੀਲ ਆਬਜੈਕਟ ਦਾ ਡੇਟਾ ਬਣਤਰ ਹੈ, ਦੂਜੀ ਇਸਦੀ ਸ਼੍ਰੇਣੀ ਹੈ):

2019.10.24 12:00:51 $1 = {
'cb' => 'TeleUpd::__ANON__',
'out' => bless( {
'filter' => bless( {}, 'Telegram::ChannelMessagesFilterEmpty' ),
'channel' => bless( {
'access_hash' => '-6698103710539760874',
'channel_id' => '1380524958'
}, 'Telegram::InputPeerChannel' ),
'pts' => '158503',
'flags' => 0,
'limit' => 0
}, 'Telegram::Updates::GetChannelDifference' ),
'req_id' => '6751291954012037292'
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'req_msg_id' => '6751291954012037292',
'result' => bless( {
'pts' => 158508,
'flags' => 3,
'final' => 1,
'new_messages' => [],
'users' => [],
'chats' => [
bless( {
'title' => 'Хулиномика',
'username' => 'hoolinomics',
'flags' => 8288,
'id' => 1380524958,
'access_hash' => '-6698103710539760874',
'broadcast' => 1,
'version' => 0,
'photo' => bless( {
'photo_small' => bless( {
'volume_id' => 246933270,
'file_reference' => '
'secret' => '1854156056801727328',
'local_id' => 228648,
'dc_id' => 2
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'local_id' => 228650,
'file_reference' => '
'secret' => '1275570353387113110',
'volume_id' => 246933270
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1531221081
}, 'Telegram::Channel' )
],
'timeout' => 300,
'other_updates' => [
bless( {
'pts_count' => 0,
'message' => bless( {
'post' => 1,
'id' => 852,
'flags' => 50368,
'views' => 8013,
'entities' => [
bless( {
'length' => 20,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 18,
'offset' => 480,
'url' => 'https://alexeymarkov.livejournal.com/[url_вырезан].html'
}, 'Telegram::MessageEntityTextUrl' )
],
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'text' => '???? 165',
'data' => 'send_reaction_0'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 9'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'message' => 'А вот и новая книга! 
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
напечатаю.',
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571724559,
'edit_date' => 1571907562
}, 'Telegram::Message' ),
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'message' => bless( {
'edit_date' => 1571907589,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'date' => 1571807301,
'message' => 'Почему Вы считаете Facebook плохой компанией? Можете прокомментировать? По-моему, это шикарная компания. Без долгов, с хорошей прибылью, а если решат дивы платить, то и еще могут нехило подорожать.
Для меня ответ совершенно очевиден: потому что Facebook делает ужасный по качеству продукт. Да, у него монопольное положение и да, им пользуется огромное количество людей. Но мир не стоит на месте. Когда-то владельцам Нокии было смешно от первого Айфона. Они думали, что лучше Нокии ничего быть не может и она навсегда останется самым удобным, красивым и твёрдым телефоном - и доля рынка это красноречиво демонстрировала. Теперь им не смешно.
Конечно, рептилоиды сопротивляются напору молодых гениев: так Цукербергом был пожран Whatsapp, потом Instagram. Но всё им не пожрать, Паша Дуров не продаётся!
Так будет и с Фейсбуком. Нельзя всё время делать говно. Кто-то когда-то сделает хороший продукт, куда всё и уйдут.
#соцсети #facebook #акции #рептилоиды',
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 452'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'text' => '???? 21',
'data' => 'send_reaction_1'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'entities' => [
bless( {
'length' => 199,
'offset' => 0
}, 'Telegram::MessageEntityBold' ),
bless( {
'length' => 8,
'offset' => 919
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 928,
'length' => 9
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 6,
'offset' => 938
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 11,
'offset' => 945
}, 'Telegram::MessageEntityHashtag' )
],
'views' => 6964,
'flags' => 50368,
'id' => 854,
'post' => 1
}, 'Telegram::Message' ),
'pts_count' => 0
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'message' => bless( {
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 213'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 8'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 2940,
'entities' => [
bless( {
'length' => 609,
'offset' => 348
}, 'Telegram::MessageEntityItalic' )
],
'flags' => 50368,
'post' => 1,
'id' => 857,
'edit_date' => 1571907636,
'date' => 1571902479,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'message' => 'Пост про 1С вызвал бурную полемику. Человек 10 (видимо, 1с-программистов) единодушно написали:
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
Я бы добавил, что блестящая у 1С дистрибуция, а маркетинг... ну, такое.'
}, 'Telegram::Message' ),
'pts_count' => 0,
'pts' => 158508
}, 'Telegram::UpdateEditChannelMessage' ),
bless( {
'pts' => 158508,
'pts_count' => 0,
'message' => bless( {
'message' => 'Здравствуйте, расскажите, пожалуйста, чем вредит экономике 1С?
// [текст сообщения вырезан чтоб не нарушать правил Хабра о рекламе]
#софт #it #экономика',
'edit_date' => 1571907650,
'date' => 1571893707,
'to_id' => bless( {
'channel_id' => 1380524958
}, 'Telegram::PeerChannel' ),
'flags' => 50368,
'post' => 1,
'id' => 856,
'reply_markup' => bless( {
'rows' => [
bless( {
'buttons' => [
bless( {
'data' => 'send_reaction_0',
'text' => '???? 360'
}, 'Telegram::KeyboardButtonCallback' ),
bless( {
'data' => 'send_reaction_1',
'text' => '???? 32'
}, 'Telegram::KeyboardButtonCallback' )
]
}, 'Telegram::KeyboardButtonRow' )
]
}, 'Telegram::ReplyInlineMarkup' ),
'views' => 4416,
'entities' => [
bless( {
'offset' => 0,
'length' => 64
}, 'Telegram::MessageEntityBold' ),
bless( {
'offset' => 1551,
'length' => 5
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'length' => 3,
'offset' => 1557
}, 'Telegram::MessageEntityHashtag' ),
bless( {
'offset' => 1561,
'length' => 10
}, 'Telegram::MessageEntityHashtag' )
]
}, 'Telegram::Message' )
}, 'Telegram::UpdateEditChannelMessage' )
]
}, 'Telegram::Updates::ChannelDifference' )
}, 'MTProto::RpcResult' )
};
2019.10.24 12:00:51 $1 = {
'in' => bless( {
'update' => bless( {
'user_id' => 2507460,
'status' => bless( {
'was_online' => 1571907651
}, 'Telegram::UserStatusOffline' )
}, 'Telegram::UpdateUserStatus' ),
'date' => 1571907650
}, 'Telegram::UpdateShort' )
};
2019.10.24 12:05:46 $1 = {
'in' => bless( {
'chats' => [],
'date' => 1571907946,
'seq' => 0,
'updates' => [
bless( {
'max_id' => 141719,
'channel_id' => 1295963795
}, 'Telegram::UpdateReadChannelInbox' )
],
'users' => []
}, 'Telegram::Updates' )
};
2019.10.24 13:01:23 $1 = {
'in' => bless( {
'server_salt' => '4914425622822907323',
'unique_id' => '5297282355827493819',
'first_msg_id' => '6751307555044380692'
}, 'MTProto::NewSessionCreated' )
};
2019.10.24 13:24:21 $1 = {
'in' => bless( {
'chats' => [
bless( {
'username' => 'freebsd_ru',
'version' => 0,
'flags' => 5440,
'title' => 'freebsd_ru',
'min' => 1,
'photo' => bless( {
'photo_small' => bless( {
'local_id' => 328733,
'volume_id' => 235140688,
'dc_id' => 2,
'file_reference' => '
'secret' => '4426006807282303416'
}, 'Telegram::FileLocation' ),
'photo_big' => bless( {
'dc_id' => 2,
'file_reference' => '
'volume_id' => 235140688,
'local_id' => 328735,
'secret' => '71251192991540083'
}, 'Telegram::FileLocation' )
}, 'Telegram::ChatPhoto' ),
'date' => 1461248502,
'id' => 1038300508,
'democracy' => 1,
'megagroup' => 1
}, 'Telegram::Channel' )
],
'users' => [
bless( {
'last_name' => 'Panov',
'flags' => 1048646,
'min' => 1,
'id' => 82234609,
'status' => bless( {}, 'Telegram::UserStatusRecently' ),
'first_name' => 'Dima'
}, 'Telegram::User' )
],
'seq' => 0,
'date' => 1571912647,
'updates' => [
bless( {
'pts' => 137596,
'message' => bless( {
'flags' => 256,
'message' => 'Создать джейл с именем покороче ??',
'to_id' => bless( {
'channel_id' => 1038300508
}, 'Telegram::PeerChannel' ),
'id' => 119634,
'date' => 1571912647,
'from_id' => 82234609
}, 'Telegram::Message' ),
'pts_count' => 1
}, 'Telegram::UpdateNewChannelMessage' )
]
}, 'Telegram::Updates' )
};

ਹਾਂ, ਜਾਣਬੁੱਝ ਕੇ ਵਿਗਾੜਨ ਵਾਲਾ ਨਹੀਂ - ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਅਜੇ ਤੱਕ ਨਹੀਂ ਪੜ੍ਹਿਆ, ਤਾਂ ਅੱਗੇ ਵਧੋ ਅਤੇ ਇਸਨੂੰ ਕਰੋ!

ਓਹ, ਵਾਈ~~... ਇਹ ਕਿਹੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ? ਕੁਝ ਬਹੁਤ ਜਾਣੂ... ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ JSON ਵਿੱਚ ਇੱਕ ਆਮ ਵੈੱਬ API ਦਾ ਡਾਟਾ ਢਾਂਚਾ ਹੈ, ਸਿਵਾਏ ਇਸ ਤੋਂ ਇਲਾਵਾ ਕਿ ਕਲਾਸਾਂ ਵੀ ਆਬਜੈਕਟ ਨਾਲ ਜੁੜੀਆਂ ਹੁੰਦੀਆਂ ਹਨ?...

ਤਾਂ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਨਿਕਲਦਾ ਹੈ... ਕਾਮਰੇਡ, ਇਹ ਸਭ ਕੀ ਹੈ?... ਇੰਨੀ ਮਿਹਨਤ - ਅਤੇ ਅਸੀਂ ਵੈੱਬ ਪ੍ਰੋਗਰਾਮਰ ਜਿੱਥੇ ਆਰਾਮ ਕਰਨ ਲਈ ਰੁਕ ਗਏ ਹੁਣੇ ਸ਼ੁਰੂ?..ਕੀ ਸਿਰਫ਼ HTTPS ਉੱਤੇ JSON ਸੌਖਾ ਨਹੀਂ ਹੋਵੇਗਾ?! ਬਦਲੇ ਵਿੱਚ ਸਾਨੂੰ ਕੀ ਮਿਲਿਆ? ਕੀ ਕੋਸ਼ਿਸ਼ ਇਸਦੀ ਕੀਮਤ ਸੀ?

ਆਉ ਮੁਲਾਂਕਣ ਕਰੀਏ ਕਿ TL+MTProto ਨੇ ਸਾਨੂੰ ਕੀ ਦਿੱਤਾ ਹੈ ਅਤੇ ਕਿਹੜੇ ਵਿਕਲਪ ਸੰਭਵ ਹਨ। ਠੀਕ ਹੈ, HTTP, ਜੋ ਕਿ ਬੇਨਤੀ-ਜਵਾਬ ਮਾਡਲ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦਾ ਹੈ, ਇੱਕ ਬੁਰਾ ਫਿਟ ਹੈ, ਪਰ ਘੱਟੋ-ਘੱਟ TLS ਦੇ ਸਿਖਰ 'ਤੇ ਕੁਝ?

ਸੰਖੇਪ ਸੀਰੀਅਲਾਈਜ਼ੇਸ਼ਨ। ਇਸ ਡੇਟਾ ਢਾਂਚੇ ਨੂੰ ਦੇਖਦਿਆਂ, JSON ਦੇ ਸਮਾਨ, ਮੈਨੂੰ ਯਾਦ ਹੈ ਕਿ ਇਸਦੇ ਬਾਈਨਰੀ ਸੰਸਕਰਣ ਹਨ. ਚਲੋ MsgPack ਨੂੰ ਨਾਕਾਫ਼ੀ ਐਕਸਟੈਂਸੀਬਲ ਵਜੋਂ ਮਾਰਕ ਕਰੀਏ, ਪਰ ਇੱਥੇ, ਉਦਾਹਰਨ ਲਈ, CBOR - ਵੈਸੇ, ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਇੱਕ ਮਿਆਰ ਹੈ RFC 7049. ਇਹ ਇਸ ਤੱਥ ਲਈ ਜ਼ਿਕਰਯੋਗ ਹੈ ਕਿ ਇਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਟੈਗਸ, ਇੱਕ ਵਿਸਥਾਰ ਵਿਧੀ ਦੇ ਰੂਪ ਵਿੱਚ, ਅਤੇ ਵਿਚਕਾਰ ਪਹਿਲਾਂ ਹੀ ਮਿਆਰੀ ਉਪਲੱਬਧ:

• 25 + 256 - ਲਾਈਨ ਨੰਬਰ ਦੇ ਹਵਾਲੇ ਨਾਲ ਵਾਰ-ਵਾਰ ਲਾਈਨਾਂ ਨੂੰ ਬਦਲਣਾ, ਅਜਿਹੀ ਸਸਤੀ ਕੰਪਰੈਸ਼ਨ ਵਿਧੀ
• 26 - ਕਲਾਸ ਦੇ ਨਾਮ ਅਤੇ ਕੰਸਟਰਕਟਰ ਆਰਗੂਮੈਂਟਸ ਦੇ ਨਾਲ ਸੀਰੀਅਲਾਈਜ਼ਡ ਪਰਲ ਆਬਜੈਕਟ
• 27 - ਕਿਸਮ ਦੇ ਨਾਮ ਅਤੇ ਕੰਸਟਰਕਟਰ ਆਰਗੂਮੈਂਟਸ ਦੇ ਨਾਲ ਲੜੀਬੱਧ ਭਾਸ਼ਾ-ਸੁਤੰਤਰ ਵਸਤੂ

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

cborlen=1039673 tl_len=1095092

ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ, ਸਿੱਟਾ: ਇੱਥੇ ਕਾਫ਼ੀ ਸਰਲ ਫਾਰਮੈਟ ਹਨ ਜੋ ਤੁਲਨਾਤਮਕ ਕੁਸ਼ਲਤਾ ਦੇ ਨਾਲ, ਸਮਕਾਲੀ ਅਸਫਲਤਾ ਜਾਂ ਅਣਜਾਣ ਪਛਾਣਕਰਤਾ ਦੀ ਸਮੱਸਿਆ ਦੇ ਅਧੀਨ ਨਹੀਂ ਹਨ।

ਤੇਜ਼ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਨਾ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਰੀਕਨੈਕਸ਼ਨ ਤੋਂ ਬਾਅਦ ਜ਼ੀਰੋ RTT (ਜਦੋਂ ਕੁੰਜੀ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਵਾਰ ਤਿਆਰ ਕੀਤੀ ਗਈ ਹੈ) - ਬਹੁਤ ਹੀ ਪਹਿਲੇ MTProto ਸੁਨੇਹੇ ਤੋਂ ਲਾਗੂ, ਪਰ ਕੁਝ ਰਿਜ਼ਰਵੇਸ਼ਨਾਂ ਦੇ ਨਾਲ - ਉਹੀ ਲੂਣ ਮਾਰੋ, ਸੈਸ਼ਨ ਖਰਾਬ ਨਹੀਂ ਹੈ, ਆਦਿ। ਇਸਦੀ ਬਜਾਏ TLS ਸਾਨੂੰ ਕੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ? ਵਿਸ਼ੇ 'ਤੇ ਹਵਾਲਾ:

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

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

ਕੁਝ ਹੋਰ ਭੁੱਲ ਗਏ ਹੋ? ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਲਿਖੋ.

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ!

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

ਤੀਜਾ ਭਾਗ ਤਕਨੀਕੀ ਭਾਗ/ਵਿਕਾਸ ਅਨੁਭਵ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਜਾਰੀ ਰੱਖੇਗਾ। ਤੁਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ ਸਿੱਖੋਗੇ:

• TL ਕਿਸਮਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਦੇ ਨਾਲ ਮਹਾਂਮਾਰੀ ਦੀ ਨਿਰੰਤਰਤਾ
• ਚੈਨਲਾਂ ਅਤੇ ਸੁਪਰਗਰੁੱਪਾਂ ਬਾਰੇ ਅਣਜਾਣ ਚੀਜ਼ਾਂ
• ਡਾਇਲਾਗ ਰੋਸਟਰ ਨਾਲੋਂ ਭੈੜੇ ਕਿਉਂ ਹਨ
• ਸੰਪੂਰਨ ਬਨਾਮ ਰਿਸ਼ਤੇਦਾਰ ਸੰਦੇਸ਼ ਐਡਰੈਸਿੰਗ ਬਾਰੇ
• ਫੋਟੋ ਅਤੇ ਚਿੱਤਰ ਵਿੱਚ ਕੀ ਅੰਤਰ ਹੈ
• ਇਮੋਜੀ ਇਟਾਲਿਕ ਟੈਕਸਟ ਵਿੱਚ ਕਿਵੇਂ ਵਿਘਨ ਪਾਉਂਦੇ ਹਨ

ਅਤੇ ਹੋਰ ਬੈਸਾਖੀਆਂ! ਵੇਖਦੇ ਰਹੇ!

ਸਰੋਤ: www.habr.com