ਮਾਡਲ ਕੰਟੈਕਸ ਪ੍ਰੋਟੋਕੋਲ (MCP) ਨੇ ਆਪਣੀ ਸੈਸ਼ਨ ਸਟੇਟ (session state) ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਜਗ੍ਹਾ ਰਸੀਦ-ਸ਼ੈਲੀ (receipt-style) ਦੀਆਂ ਬੇਨਤੀਆਂ ਅਤੇ ਇੱਕ ਨਵੇਂ server/discover ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੈ। ਡਿਵੈਲਪਰ ਹੁਣ AWS Lambda ਵਰਗੇ ਸਰਵਰਲੈੱਸ (serverless) ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ MCP ਚਲਾ ਸਕਦੇ ਹਨ ਅਤੇ ਉਸ "ਸਿੰਗਲ ਵੇਟਰ" (single waiter) ਦੀ ਰੁਕਾਵਟ ਤੋਂ ਬਚ ਸਕਦੇ ਹਨ ਜਿਸ ਨੇ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ ਹੈ।

ਪੁਰਾਣਾ ਮਾਡਲ ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਸੀ

ਸ਼ੁਰੂਆਤ ਵਿੱਚ MCP ਲਈ ਇੱਕ ਖਾਸ ਸਰਵਰ ਨਾਲ ਲਗਾਤਾਰ ਕਨੈਕਸ਼ਨ (persistent connection) ਦੀ ਲੋੜ ਹੁੰਦੀ ਸੀ। ਸਰਵਰ ਯੂਜ਼ਰ ਦਾ "ਟੇਬਲ ਨੰਬਰ" — ਇੱਕ ਗੁਪਤ ਸੈਸ਼ਨ ਜੋ ਕੰਟੈਕਸ, ਨਿਯਮਾਂ ਅਤੇ ਲੰਬਿਤ ਕਾਰਵਾਈਆਂ (pending actions) ਨੂੰ ਸਟੋਰ ਕਰਦਾ ਸੀ — ਰੱਖਦਾ ਸੀ। ਜਦੋਂ ਉਹ ਸਰਵਰ ਕ੍ਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਸੀ, ਤਾਂ ਸੈਸ਼ਨ ਖਤਮ ਹੋ ਜਾਂਦਾ ਸੀ ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂਆਤ ਕਰਨੀ ਪੈਂਦੀ ਸੀ।

ਅਪਡੇਟ ਵਿੱਚ ਕੀ ਵੱਖਰਾ ਹੈ

  • ਕੋਈ ਸੈਸ਼ਨ ਨਹੀਂ – ਹਰ ਬੇਨਤੀ ਵਿੱਚ ਉਹ ਸਭ ਕੁਝ ਹੁੰਦਾ ਹੈ ਜਿਸਦੀ ਸਰਵਰ ਨੂੰ ਲੋੜ ਹੈ, ਜਿਵੇਂ ਕਿ ਰੈਸਟੋਰੈਂਟ ਦੀ ਰਸੀਦ ਜਿਸਨੂੰ ਕੋਈ ਵੀ ਕੈਸ਼ੀਅਰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ। "initialize" ਹੈਂਡਸ਼ੇਕ (handshake) ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ।
  • ਰਸੀਦ ਮਾਡਲ – ਹਰ ਬੇਨਤੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਮੈਟਾ ਬਲਾਕ (meta block) ਹੁੰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਵਰਜ਼ਨ ਦੀ ਜਾਣਕਾਰੀ ਅਤੇ ਲੋੜੀਂਦੇ ਪੈਰਾਮੀਟਰ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਸਰਵਰ ਬੇਨਤੀ ਨੂੰ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਫਿਰ resultType, ttlMs (ਮਿਲੀਸੈਕਿੰਡ ਵਿੱਚ time-to-live), ਅਤੇ cacheScope ਦੇ ਨਾਲ ਨਤੀਜਾ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਫੀਲਡਸ ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਨੂੰ ਸੁਰੱਖਿਅਤ ਰੂਪ ਵਿੱਚ ਕੈਸ਼ (cache) ਕਰਨ ਅਤੇ ਇਹ ਜਾਣਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਇਹ ਕਦੋਂ ਖਤਮ ਹੋਵੇਗਾ।
  • Server/discover – ਇੱਕ ਨਵਾਂ ਕਮਾਂਡ ਕਲਾਇੰਟ ਨੂੰ ਸਰਵਰ ਦੀਆਂ ਮੌਜੂਦਾ ਸਮਰੱਥਾਵਾਂ ਬਾਰੇ ਪੁੱਛਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਸਦਾ ਜਵਾਬ ਤੁਰੰਤ ਮਿਲਦਾ ਹੈ ਅਤੇ ਪਿਛਲੀ ਗੱਲਬਾਤ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਦਾ।
  • Subscriptions/listen – ਇਹ ਇੱਕ ਬਜ਼ਰ (buzzer) ਵਾਂਗ ਕੰਮ ਕਰਦਾ ਹੈ: ਕਲਾਇੰਟ ਅਪਡੇਟਸ ਲਈ ਸਬਸਕ੍ਰਾਈਬ ਕਰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ਼ ਉਦੋਂ ਹੀ ਸੂਚਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕੁਝ ਬਦਲਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਪੋਲਿੰਗ ਟ੍ਰੈਫਿਕ (polling traffic) ਘਟ ਜਾਂਦਾ ਹੈ।
  • Input_required flow – ਜੇਕਰ ਸਰਵਰ ਨੂੰ ਹੋਰ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਕਲਾਇੰਟ ਕੋਲ ਵਾਪਸ ਜਾਣ ਦੀ ਬਜਾਏ input_required ਜਵਾਬ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਅਗਲੀ ਬੇਨਤੀ ਵਿੱਚ ਲੋੜੀਂਦਾ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਕਿਉਂਕਿ ਸਰਵਰ ਹੁਣ ਸਟੇਟ (state) ਨਹੀਂ ਰੱਖਦਾ, ਇਸ ਲਈ ਕੋਈ ਵੀ ਸਟੇਟਲੈੱਸ (stateless) ਕੰਪਿਊਟ ਵਾਤਾਵਰਣ MCP ਐਂਡਪੁਆਇੰਟਸ (endpoints) ਨੂੰ ਹੋਸਟ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਫੰਕਸ਼ਨ ਜੋ ਮੰਗ 'ਤੇ ਚੱਲਦੇ ਹਨ, ਰੁਕ ਜਾਂਦੇ ਹਨ, ਜਾਂ ਵੱਖ-ਵੱਖ ਜ਼ੋਨਾਂ ਵਿੱਚ ਮਾਈਗ੍ਰੇਟ ਹੁੰਦੇ ਹਨ, ਉਹ ਗੱਲਬਾਤ ਨੂੰ ਤੋੜੇ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਭਾਲ ਸਕਦੇ ਹਨ।

ਕਿਸਦਾ ਫਾਇਦਾ ਹੋਵੇਗਾ, ਕਿਸਨੂੰ ਚਿੰਤਾ ਹੋਵੇਗੀ

AI ਫਰੰਟ-ਐਂਡ ਬਣਾਉਣ ਵਾਲੇ ਡਿਵੈਲਪਰ – ਵਧੇਰੇ ਸਰਲ ਅਤੇ ਭਰੋਸੇਯੋਗ ਬੈਕ-ਐਂਡ ਪ੍ਰਾਪਤ ਕਰਨਗੇ। ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਟੀਮਾਂ – ਸਸਤੀਆਂ, ਆਟੋ-ਸਕੇਲਿੰਗ ਸੇਵਾਵਾਂ 'ਤੇ MCP ਪ੍ਰੋਵੀਜ਼ਨ ਕਰ ਸਕਦੀਆਂ ਹਨ। MCP ਸਰਵਰ ਮੇਨਟੇਨਰ – ttlMs, cacheScope ਜਾਰੀ ਕਰਨ ਲਈ ਅਤੇ server/discover ਕੰਟਰੈਕਟ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਹੈਂਡਲਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਪਵੇਗਾ। ਉਹ ਕੋਡ ਜੋ ਲਗਾਤਾਰ ਸੈਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਸੀ, ਉਸਨੂੰ ਰੀਫੈਕਟਰੀੰਗ (refactoring) ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਸਖ਼ਤ ਕੰਪਲਾਇੰਸ ਵਾਲੇ ਉਦਯੋਗ – ਸਪਸ਼ਟ ਡੇਟਾ-ਲਾਈਫਸਾਈਕਲ ਕੰਟਰੋਲ ਤੋਂ ਲਾਭ ਪ੍ਰਾਪਤ ਕਰਨਗੇ।

ਲੁਕੀ ਹੋਈ ਜਾਣਕਾਰੀ: ਵਰਜ਼ਨ ਨੈਗੋਸ਼ੀਏਸ਼ਨ

ਹਰ ਰਸੀਦ ਵਿੱਚ ਇੱਕ ਛੋਟਾ ਮੈਟਾ ਬਲਾਕ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਉਸ ਪ੍ਰੋਟੋਕੋਲ ਵਰਜ਼ਨ ਦਾ ਪ੍ਰਚਾਰ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਕਲਾਇੰਟ ਉਮੀਦ ਕਰਦਾ ਹੈ।

ਕੀ ਅਜੇ ਵੀ ਅਨਿਸ਼ਚਿਤ ਹੈ

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

ਸਿੱਟਾ

ਸੈਸ਼ਨ ਸਟੇਟ ਨੂੰ ਹਟਾ ਕੇ ਅਤੇ ਹਰ ਇੰਟਰੈਕਸ਼ਨ ਨੂੰ ਇੱਕ ਸਵੈ-ਨਿਰਭਰ ਰਸੀਦ ਵਿੱਚ ਬਦਲ ਕੇ, MCP ਹੁਣ ਸਰਵਰਲੈੱਸ ਈਕੋਸਿਸਟਮਾਂ ਵਿੱਚ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ। ਇਹ ਤਬਦੀਲੀ MCP ਨੂੰ ਵਧੇਰੇ ਸਥਿਰ ਅਤੇ ਸਕੈਲੇਬਲ (scalable) ਬਣਾਉਂਦੀ ਹੈ, ਜਿਸ ਨਾਲ ਸਰਵਰ ਕਿਤੇ ਵੀ ਚੱਲ ਸਕਦੇ ਹਨ ਅਤੇ ਕਿਸੇ ਵੀ ਆਮ ਵੈੱਬ ਸੇਵਾ ਵਾਂਗ ਵਧ ਸਕਦੇ ਹਨ।