یہ باب HTTPS کا استعمال کرتے ہوئے ماڈل کانٹیکسٹ پروٹوکول (MCP) کے ساتھ محفوظ، قابل توسیع، اور حقیقی وقت کی اسٹریمینگ کو نافذ کرنے کے لیے ایک جامع گائیڈ فراہم کرتا ہے۔ اس میں اسٹریمینگ کی ضرورت، دستیاب ٹرانسپورٹ میکانزم، MCP میں اسٹریم ایبل HTTP کو نافذ کرنے کا طریقہ، سیکیورٹی کے بہترین طریقے، SSE سے منتقلی، اور اپنی اسٹریمینگ MCP ایپلیکیشنز بنانے کے لیے عملی رہنمائی شامل ہے۔
یہ سیکشن MCP میں دستیاب مختلف ٹرانسپورٹ میکانزم اور کلائنٹس اور سرورز کے درمیان حقیقی وقت کی مواصلات کو فعال کرنے کے لیے ان کے کردار کو دریافت کرتا ہے۔
ٹرانسپورٹ میکانزم اس بات کی وضاحت کرتا ہے کہ کلائنٹ اور سرور کے درمیان ڈیٹا کا تبادلہ کیسے ہوتا ہے۔ MCP مختلف ماحول اور ضروریات کے مطابق متعدد ٹرانسپورٹ اقسام کی حمایت کرتا ہے:
- stdio: معیاری ان پٹ/آؤٹ پٹ، مقامی اور CLI پر مبنی ٹولز کے لیے موزوں۔ سادہ لیکن ویب یا کلاؤڈ کے لیے موزوں نہیں۔
- SSE (سرور-سینٹ ایونٹس): سرورز کو حقیقی وقت کی اپ ڈیٹس HTTP کے ذریعے کلائنٹس کو بھیجنے کی اجازت دیتا ہے۔ ویب UI کے لیے اچھا ہے، لیکن توسیع پذیری اور لچک میں محدود۔
- Streamable HTTP: جدید HTTP پر مبنی اسٹریمینگ ٹرانسپورٹ، نوٹیفیکیشنز اور بہتر توسیع پذیری کی حمایت کرتا ہے۔ زیادہ تر پروڈکشن اور کلاؤڈ منظرناموں کے لیے تجویز کردہ۔
نیچے دیے گئے موازنہ جدول پر نظر ڈالیں تاکہ ان ٹرانسپورٹ میکانزم کے درمیان فرق کو سمجھا جا سکے:
| ٹرانسپورٹ | حقیقی وقت کی اپ ڈیٹس | اسٹریمینگ | توسیع پذیری | استعمال کا کیس |
|---|---|---|---|---|
| stdio | نہیں | نہیں | کم | مقامی CLI ٹولز |
| SSE | ہاں | ہاں | درمیانی | ویب، حقیقی وقت کی اپ ڈیٹس |
| Streamable HTTP | ہاں | ہاں | اعلی | کلاؤڈ، ملٹی کلائنٹ |
ٹپ: صحیح ٹرانسپورٹ کا انتخاب کارکردگی، توسیع پذیری، اور صارف کے تجربے پر اثر ڈالتا ہے۔ Streamable HTTP جدید، توسیع پذیر، اور کلاؤڈ کے لیے تیار ایپلیکیشنز کے لیے تجویز کردہ ہے۔
پچھلے ابواب میں آپ کو دکھائے گئے stdio اور SSE ٹرانسپورٹ کو نوٹ کریں اور اس باب میں شامل Streamable HTTP ٹرانسپورٹ کو دیکھیں۔
حقیقی وقت کی مواصلات کے نظام کو مؤثر طریقے سے نافذ کرنے کے لیے اسٹریمینگ کے بنیادی تصورات اور محرکات کو سمجھنا ضروری ہے۔
اسٹریمینگ نیٹ ورک پروگرامنگ میں ایک تکنیک ہے جو ڈیٹا کو چھوٹے، قابل انتظام حصوں یا ایونٹس کی ترتیب کے طور پر بھیجنے اور وصول کرنے کی اجازت دیتی ہے، بجائے اس کے کہ پورے جواب کے تیار ہونے کا انتظار کیا جائے۔ یہ خاص طور پر مفید ہے:
- بڑے فائلز یا ڈیٹا سیٹس۔
- حقیقی وقت کی اپ ڈیٹس (مثلاً چیٹ، پروگریس بارز)۔
- طویل مدتی حسابات جہاں آپ صارف کو مطلع رکھنا چاہتے ہیں۔
یہاں اسٹریمینگ کے بارے میں اعلی سطح پر جاننے کی ضرورت ہے:
- ڈیٹا بتدریج فراہم کیا جاتا ہے، ایک ساتھ نہیں۔
- کلائنٹ ڈیٹا کو جیسے ہی وصول کرتا ہے، پروسیس کر سکتا ہے۔
- محسوس شدہ تاخیر کو کم کرتا ہے اور صارف کے تجربے کو بہتر بناتا ہے۔
اسٹریمینگ استعمال کرنے کی وجوہات درج ذیل ہیں:
- صارفین کو فوری فیڈبیک ملتا ہے، صرف آخر میں نہیں۔
- حقیقی وقت کی ایپلیکیشنز اور جوابدہ UI کو فعال کرتا ہے۔
- نیٹ ورک اور کمپیوٹ وسائل کا زیادہ مؤثر استعمال۔
یہاں ایک سادہ مثال ہے کہ اسٹریمینگ کو کیسے نافذ کیا جا سکتا ہے:
سرور (Python، FastAPI اور StreamingResponse کا استعمال کرتے ہوئے):
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
import time
app = FastAPI()
async def event_stream():
for i in range(1, 6):
yield f"data: Message {i}\n\n"
time.sleep(1)
@app.get("/stream")
def stream():
return StreamingResponse(event_stream(), media_type="text/event-stream")کلائنٹ (Python، requests کا استعمال کرتے ہوئے):
import requests
with requests.get("http://localhost:8000/stream", stream=True) as r:
for line in r.iter_lines():
if line:
print(line.decode())یہ مثال ایک سرور کو دکھاتی ہے جو کلائنٹ کو پیغامات کی ایک سیریز بھیجتا ہے جیسے ہی وہ دستیاب ہوتے ہیں، بجائے اس کے کہ تمام پیغامات کے تیار ہونے کا انتظار کرے۔
یہ کیسے کام کرتا ہے:
- سرور ہر پیغام کو جیسے ہی تیار ہوتا ہے، بھیجتا ہے۔
- کلائنٹ ہر حصہ کو جیسے ہی وصول کرتا ہے، پرنٹ کرتا ہے۔
ضروریات:
- سرور کو ایک اسٹریمینگ جواب استعمال کرنا چاہیے (مثلاً، FastAPI میں
StreamingResponse)۔ - کلائنٹ کو جواب کو اسٹریم کے طور پر پروسیس کرنا چاہیے (
stream=Truerequests میں)۔ - مواد کی قسم عام طور پر
text/event-streamیاapplication/octet-streamہوتی ہے۔
سرور (Java، Spring Boot اور Server-Sent Events کا استعمال کرتے ہوئے):
@RestController
public class CalculatorController {
@GetMapping(value = "/calculate", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public Flux<ServerSentEvent<String>> calculate(@RequestParam double a,
@RequestParam double b,
@RequestParam String op) {
double result;
switch (op) {
case "add": result = a + b; break;
case "sub": result = a - b; break;
case "mul": result = a * b; break;
case "div": result = b != 0 ? a / b : Double.NaN; break;
default: result = Double.NaN;
}
return Flux.<ServerSentEvent<String>>just(
ServerSentEvent.<String>builder()
.event("info")
.data("Calculating: " + a + " " + op + " " + b)
.build(),
ServerSentEvent.<String>builder()
.event("result")
.data(String.valueOf(result))
.build()
)
.delayElements(Duration.ofSeconds(1));
}
}کلائنٹ (Java، Spring WebFlux WebClient کا استعمال کرتے ہوئے):
@SpringBootApplication
public class CalculatorClientApplication implements CommandLineRunner {
private final WebClient client = WebClient.builder()
.baseUrl("http://localhost:8080")
.build();
@Override
public void run(String... args) {
client.get()
.uri(uriBuilder -> uriBuilder
.path("/calculate")
.queryParam("a", 7)
.queryParam("b", 5)
.queryParam("op", "mul")
.build())
.accept(MediaType.TEXT_EVENT_STREAM)
.retrieve()
.bodyToFlux(String.class)
.doOnNext(System.out::println)
.blockLast();
}
}Java نفاذ کے نوٹس:
- Spring Boot کے ری ایکٹیو اسٹیک کے ساتھ
Fluxکا استعمال کرتا ہے اسٹریمینگ کے لیے۔ ServerSentEventایونٹ کی اقسام کے ساتھ ساختی ایونٹ اسٹریمینگ فراہم کرتا ہے۔WebClientکے ساتھbodyToFlux()ری ایکٹیو اسٹریمینگ کھپت کو فعال کرتا ہے۔delayElements()ایونٹس کے درمیان پروسیسنگ وقت کی نقل کرتا ہے۔- ایونٹس میں اقسام (
info,result) ہو سکتی ہیں بہتر کلائنٹ ہینڈلنگ کے لیے۔
اسٹریمینگ کے "کلاسیکل" طریقے اور MCP میں اسٹریمینگ کے کام کرنے کے طریقے کے درمیان فرق کو اس طرح دکھایا جا سکتا ہے:
| خصوصیت | کلاسک HTTP اسٹریمینگ | MCP اسٹریمینگ (نوٹیفیکیشنز) |
|---|---|---|
| مرکزی جواب | چنکڈ | ایک، آخر میں |
| پروگریس اپ ڈیٹس | ڈیٹا چنکس کے طور پر بھیجی جاتی ہیں | نوٹیفیکیشنز کے طور پر بھیجی جاتی ہیں |
| کلائنٹ کی ضروریات | اسٹریم کو پروسیس کرنا ضروری ہے | میسج ہینڈلر کو نافذ کرنا ضروری ہے |
| استعمال کا کیس | بڑی فائلز، AI ٹوکن اسٹریمز | پروگریس، لاگز، حقیقی وقت کی فیڈبیک |
مزید برآں، یہاں کچھ کلیدی فرق ہیں:
-
مواصلاتی پیٹرن:
- کلاسک HTTP اسٹریمینگ: ڈیٹا کو چنکس میں بھیجنے کے لیے سادہ چنکڈ ٹرانسفر انکوڈنگ کا استعمال کرتا ہے۔
- MCP اسٹریمینگ: JSON-RPC پروٹوکول کے ساتھ ایک ساختی نوٹیفیکیشن سسٹم کا استعمال کرتا ہے۔
-
پیغام کی شکل:
- کلاسک HTTP: نیو لائنز کے ساتھ سادہ متن چنکس۔
- MCP: میٹا ڈیٹا کے ساتھ ساختی LoggingMessageNotification اشیاء۔
-
کلائنٹ نفاذ:
- کلاسک HTTP: سادہ کلائنٹ جو اسٹریمینگ جوابات کو پروسیس کرتا ہے۔
- MCP: زیادہ نفیس کلائنٹ جو مختلف قسم کے پیغامات کو پروسیس کرنے کے لیے میسج ہینڈلر رکھتا ہے۔
-
پروگریس اپ ڈیٹس:
- کلاسک HTTP: پروگریس مرکزی جواب اسٹریم کا حصہ ہے۔
- MCP: پروگریس الگ نوٹیفیکیشن پیغامات کے ذریعے بھیجی جاتی ہے جبکہ مرکزی جواب آخر میں آتا ہے۔
کلاسیکل اسٹریمینگ (جیسے /stream اینڈ پوائنٹ کا استعمال) کو نافذ کرنے اور MCP کے ذریعے اسٹریمینگ کے درمیان انتخاب کرنے کے بارے میں کچھ سفارشات ہیں۔
-
سادہ اسٹریمینگ ضروریات کے لیے: کلاسک HTTP اسٹریمینگ کو نافذ کرنا آسان ہے اور بنیادی اسٹریمینگ ضروریات کے لیے کافی ہے۔
-
پیچیدہ، انٹرایکٹو ایپلیکیشنز کے لیے: MCP اسٹریمینگ ایک زیادہ ساختی نقطہ نظر فراہم کرتا ہے جس میں زیادہ میٹا ڈیٹا اور نوٹیفیکیشنز اور حتمی نتائج کے درمیان علیحدگی ہوتی ہے۔
-
AI ایپلیکیشنز کے لیے: MCP کا نوٹیفیکیشن سسٹم خاص طور پر طویل مدتی AI کاموں کے لیے مفید ہے جہاں آپ صارفین کو پروگریس کے بارے میں مطلع رکھنا چاہتے ہیں۔
ٹھیک ہے، تو آپ نے کلاسیکل اسٹریمینگ اور MCP میں اسٹریمینگ کے فرق پر کچھ سفارشات اور موازنہ دیکھا۔ آئیے تفصیل میں جائیں کہ آپ MCP میں اسٹریمینگ کو کیسے فائدہ اٹھا سکتے ہیں۔
MCP فریم ورک کے اندر اسٹریمینگ کے کام کرنے کو سمجھنا ان ایپلیکیشنز بنانے کے لیے ضروری ہے جو طویل مدتی آپریشنز کے دوران صارفین کو حقیقی وقت کی فیڈبیک فراہم کرتی ہیں۔
MCP میں، اسٹریمینگ کا مطلب مرکزی جواب کو چنکس میں بھیجنا نہیں ہے، بلکہ نوٹیفیکیشنز کو کلائنٹ کو بھیجنا ہے جب ایک ٹول درخواست کو پروسیس کر رہا ہو۔ یہ نوٹیفیکیشنز پروگریس اپ ڈیٹس، لاگز، یا دیگر ایونٹس شامل کر سکتے ہیں۔
مرکزی نتیجہ اب بھی ایک واحد جواب کے طور پر بھیجا جاتا ہے۔ تاہم، پروسیسنگ کے دوران نوٹیفیکیشنز الگ پیغامات کے طور پر بھیجی جا سکتی ہیں اور اس طرح کلائنٹ کو حقیقی وقت میں اپ ڈیٹ کر سکتی ہیں۔ کلائنٹ کو ان نوٹیفیکیشنز کو ہینڈل اور ڈسپلے کرنے کے قابل ہونا چاہیے۔
ہم نے "نوٹیفیکیشن" کہا، MCP کے سیاق و سباق میں اس کا کیا مطلب ہے؟
نوٹیفیکیشن ایک پیغام ہے جو سرور سے کلائنٹ کو بھیجا جاتا ہے تاکہ طویل مدتی آپریشن کے دوران پروگریس، اسٹیٹس، یا دیگر ایونٹس کے بارے میں مطلع کیا جا سکے۔ نوٹیفیکیشنز شفافیت اور صارف کے تجربے کو بہتر بناتے ہیں۔
مثال کے طور پر، کلائنٹ کو ابتدائی ہینڈ شیک کے بعد سرور کے ساتھ ایک نوٹیفیکیشن بھیجنا چاہیے۔
نوٹیفیکیشن JSON پیغام کی طرح دکھائی دیتا ہے:
{
jsonrpc: "2.0";
method: string;
params?: {
[key: string]: unknown;
};
}نوٹیفیکیشنز MCP میں ایک موضوع سے تعلق رکھتے ہیں جسے "Logging" کہا جاتا ہے۔
لاگنگ کو کام کرنے کے لیے، سرور کو اسے ایک فیچر/صلاحیت کے طور پر فعال کرنا ہوگا جیسے:
{
"capabilities": {
"logging": {}
}
}Note
استعمال شدہ SDK پر منحصر ہے، لاگنگ پہلے سے فعال ہو سکتی ہے، یا آپ کو اپنے سرور کی کنفیگریشن میں اسے واضح طور پر فعال کرنے کی ضرورت ہو سکتی ہے۔
نوٹیفیکیشنز کی مختلف اقسام ہیں:
| سطح | وضاحت | استعمال کا کیس |
|---|---|---|
| debug | تفصیلی ڈیبگنگ معلومات | فنکشن انٹری/ایگزٹ پوائنٹس |
| info | عمومی معلوماتی پیغامات | آپریشن پروگریس اپ ڈیٹس |
| notice | معمولی لیکن اہم ایونٹس | کنفیگریشن تبدیلیاں |
| warning | انتباہی حالات | پرانی فیچر کا استعمال |
| error | غلطی کے حالات | آپریشن کی ناکامی |
| critical | اہم حالات | سسٹم کے اجزاء کی ناکامی |
| alert | فوری کارروائی کی ضرورت ہے | ڈیٹا کرپشن کا پتہ چلا |
| emergency | سسٹم ناقابل استعمال ہے | مکمل سسٹم کی ناکامی |
نوٹیفیکیشنز کو MCP میں نافذ کرنے کے لیے، آپ کو حقیقی وقت کی اپ ڈیٹس کو ہینڈل کرنے کے لیے سرور اور کلائنٹ دونوں سائیڈز کو سیٹ اپ کرنا ہوگا۔ یہ آپ کی ایپلیکیشن کو طویل مدتی آپریشنز کے دوران صارفین کو فوری فیڈبیک فراہم کرنے کی اجازت دیتا ہے۔
آئیے سرور سائیڈ سے شروع کریں۔ MCP میں، آپ ایسے ٹولز کی وضاحت کرتے ہیں جو درخواستوں کو پروسیس کرتے وقت نوٹیفیکیشنز بھیج سکتے ہیں۔ سرور کلائنٹ کو پیغامات بھیجنے کے لیے کانٹیکسٹ آبجیکٹ (عام طور پر ctx) استعمال کرتا ہے۔
@mcp.tool(description="A tool that sends progress notifications")
async def process_files(message: str, ctx: Context) -> TextContent:
await ctx.info("Processing file 1/3...")
await ctx.info("Processing file 2/3...")
await ctx.info("Processing file 3/3...")
return TextContent(type="text", text=f"Done: {message}")پچھلی مثال میں، process_files ٹول ہر فائل کو پروسیس کرتے وقت کلائنٹ کو تین نوٹیفیکیشنز بھیجتا ہے۔ ctx.info() طریقہ معلوماتی پیغامات بھیجنے کے لیے استعمال کیا جاتا ہے۔
مزید برآں، نوٹیفیکیشنز کو فعال کرنے کے لیے، یقینی بنائیں کہ آپ کا سرور اسٹریمینگ ٹرانسپورٹ (جیسے streamable-http) استعمال کرتا ہے اور آپ کا کلائنٹ نوٹیفیکیشنز کو پروسیس کرنے کے لیے میسج ہینڈلر نافذ کرتا ہے۔ یہاں بتایا گیا ہے کہ آپ اپنے سرور کو streamable-http ٹرانسپورٹ استعمال کرنے کے لیے کیسے سیٹ اپ کر سکتے ہیں:
mcp.run(transport="streamable-http")[Tool("A tool that sends progress notifications")]
public async Task<TextContent> ProcessFiles(string message, ToolContext ctx)
{
await ctx.Info("Processing file 1/3...");
await ctx.Info("Processing file 2/3...");
await ctx.Info("Processing file 3/3...");
return new TextContent
{
Type = "text",
Text = $"Done: {message}"
};
}اس .NET مثال میں، ProcessFiles ٹول Tool ایٹریبیوٹ کے ساتھ سجایا گیا ہے اور ہر فائل کو پروسیس کرتے وقت کلائنٹ کو تین نوٹیفیکیشنز بھیجتا ہے۔ ctx.Info() طریقہ معلوماتی پیغامات بھیجنے کے لیے استعمال کیا جاتا ہے۔
اپنے .NET MCP سرور میں نوٹیفیکیشنز کو فعال کرنے کے لیے، یقینی بنائیں کہ آپ اسٹریمینگ ٹرانسپورٹ استعمال کر رہے ہیں:
var builder = McpBuilder.Create();
await builder
.UseStreamableHttp() // Enable streamable HTTP transport
.Build()
.RunAsync();کلائنٹ کو ایک میسج ہینڈلر نافذ کرنا ہوگا جو نوٹیفیکیشنز کو وصول اور ڈسپلے کرے جیسے ہی وہ آئیں۔
async def message_handler(message):
if isinstance(message, types.ServerNotification):
print("NOTIFICATION:", message)
else:
print("SERVER MESSAGE:", message)
async with ClientSession(
read_stream,
write_stream,
logging_callback=logging_collector,
message_handler=message_handler,
) as session:پچھلے کوڈ میں، message_handler فنکشن چیک کرتا ہے کہ آیا آنے والا پیغام نوٹیفیکیشن ہے۔ اگر ایسا ہے، تو یہ نوٹیفیکیشن پرنٹ کرتا ہے؛ ورنہ، اسے ایک عام سرور پیغام کے طور پر پروسیس کرتا ہے۔ یہ بھی نوٹ کریں کہ ClientSession کو نوٹیفیکیشنز کو ہینڈل کرنے کے لیے message_handler کے ساتھ شروع کیا گیا ہے۔
// Define a message handler
void MessageHandler(IJsonRpcMessage message)
{
if (message is ServerNotification notification)
{
Console.WriteLine($"NOTIFICATION: {notification}");
}
else
{
Console.WriteLine($"SERVER MESSAGE: {message}");
}
}
// Create and use a client session with the message handler
var clientOptions = new ClientSessionOptions
{
MessageHandler = MessageHandler,
LoggingCallback = (level, message) => Console.WriteLine($"[{level}] {message}")
};
using var client = new ClientSession(readStream, writeStream, clientOptions);
await client.InitializeAsync();
// Now the client will process notifications through the MessageHandlerاس .NET مثال میں، MessageHandler فنکشن چیک کرتا ہے کہ آیا آنے والا پیغام نوٹیفیکیشن ہے۔ اگر ایسا ہے، تو یہ نوٹیفیکیشن پرنٹ کرتا ہے؛ ورنہ، اسے ایک عام سرور پیغام کے طور پر پروسیس کرتا ہے۔ ClientSession کو ClientSessionOptions کے ذریعے میسج ہینڈلر کے ساتھ شروع کیا گیا ہے۔
نوٹیفیکیشنز کو فعال کرنے کے لیے، یقینی بنائیں کہ آپ کا سرور اسٹریمینگ ٹرانسپورٹ (جیسے streamable-http) استعمال کرتا ہے اور آپ کا کلائنٹ نوٹیفیکیشنز کو پروسیس کرنے کے لیے میسج ہینڈلر نافذ کرتا ہے۔
یہ سیکشن MCP میں پروگریس نوٹیفیکیشنز کے تصور، ان کی اہمیت، اور Streamable HTTP کا استعمال کرتے ہوئے انہیں نافذ کرنے کا طریقہ بیان کرتا ہے۔ آپ کو اپنی سمجھ کو مضبوط کرنے کے لیے ایک عملی اسائنمنٹ بھی ملے گا۔
پروگریس نوٹیفیکیشنز حقیقی وقت کے پیغامات ہیں جو سرور سے کلائنٹ کو طویل مدتی آپریشنز کے دوران بھیجے جاتے ہیں۔ پورے عمل کے ختم ہونے کا انتظار کرنے کے بجائے، سرور کلائنٹ کو موجودہ اسٹیٹس کے بارے میں اپ ڈیٹ رکھتا ہے۔ یہ شفافیت، صارف کے تجربے کو بہتر بناتا ہے، اور ڈیبگنگ کو آسان بناتا ہے۔
مثال:
"Processing document 1/10"
"Processing document 2/10"
...
"Processing complete!"
پروگریس نوٹیفیکیشنز کئی وجوہات کے لیے ضروری ہیں:
-
بہتر صارف کا تجربہ: صارفین کام کے جاری رہنے کے دوران اپ ڈیٹس دیکھتے ہیں، صرف آخر میں نہیں۔
-
حقیقی وقت کی فیڈبیک: کلائنٹس پروگریس بارز یا لاگز دکھا سکتے ہیں، ایپ کو جوابدہ بناتے ہیں۔
-
آسان ڈیبگنگ اور مانیٹرنگ: ڈویلپرز اور صارفین دیکھ سکتے ہیں کہ ایس ایس ای سے اسٹریمیبل ایچ ٹی ٹی پی پر اپ گریڈ کرنے کے دو اہم وجوہات ہیں:
-
اسٹریمیبل ایچ ٹی ٹی پی ایس ایس ای کے مقابلے میں بہتر اسکیل ایبلٹی، مطابقت، اور زیادہ بھرپور نوٹیفکیشن سپورٹ فراہم کرتا ہے۔
-
یہ نئی ایم سی پی ایپلیکیشنز کے لیے تجویز کردہ ٹرانسپورٹ ہے۔
یہاں بتایا گیا ہے کہ آپ اپنی ایم سی پی ایپلیکیشنز میں ایس ایس ای سے اسٹریمیبل ایچ ٹی ٹی پی پر کیسے منتقل ہو سکتے ہیں:
- سرور کوڈ کو اپ ڈیٹ کریں تاکہ
mcp.run()میںtransport="streamable-http"استعمال کریں۔ - کلائنٹ کوڈ کو اپ ڈیٹ کریں تاکہ ایس ایس ای کلائنٹ کے بجائے
streamablehttp_clientاستعمال کریں۔ - کلائنٹ میں ایک میسج ہینڈلر نافذ کریں تاکہ نوٹیفکیشنز کو پروسیس کیا جا سکے۔
- موجودہ ٹولز اور ورک فلو کے ساتھ مطابقت کی جانچ کریں۔
منتقلی کے دوران موجودہ ایس ایس ای کلائنٹس کے ساتھ مطابقت برقرار رکھنا تجویز کیا جاتا ہے۔ یہاں کچھ حکمت عملیاں ہیں:
- آپ مختلف اینڈ پوائنٹس پر دونوں ٹرانسپورٹس (ایس ایس ای اور اسٹریمیبل ایچ ٹی ٹی پی) کو چلا کر دونوں کی سپورٹ فراہم کر سکتے ہیں۔
- کلائنٹس کو نئے ٹرانسپورٹ پر بتدریج منتقل کریں۔
منتقلی کے دوران درج ذیل چیلنجز کو حل کرنا یقینی بنائیں:
- تمام کلائنٹس کو اپ ڈیٹ کرنا
- نوٹیفکیشن کی ترسیل میں فرق کو ہینڈل کرنا
ایچ ٹی ٹی پی پر مبنی ٹرانسپورٹس جیسے اسٹریمیبل ایچ ٹی ٹی پی کے ساتھ کسی بھی سرور کو نافذ کرتے وقت سیکیورٹی کو اولین ترجیح دینی چاہیے۔
ایچ ٹی ٹی پی پر مبنی ٹرانسپورٹس کے ساتھ ایم سی پی سرورز کو نافذ کرتے وقت، سیکیورٹی ایک اہم تشویش بن جاتی ہے جس کے لیے مختلف حملوں کے ویکٹرز اور حفاظتی میکانزم پر محتاط توجہ کی ضرورت ہوتی ہے۔
ایچ ٹی ٹی پی پر ایم سی پی سرورز کو ایکسپوز کرتے وقت سیکیورٹی بہت اہم ہے۔ اسٹریمیبل ایچ ٹی ٹی پی نئے حملے کے راستے متعارف کراتا ہے اور محتاط کنفیگریشن کی ضرورت ہوتی ہے۔
یہاں کچھ اہم سیکیورٹی تحفظات ہیں:
- اورجن ہیڈر کی توثیق: ڈی این ایس ری بائنڈنگ حملوں سے بچنے کے لیے ہمیشہ
Originہیڈر کی توثیق کریں۔ - لوکل ہوسٹ بائنڈنگ: مقامی ترقی کے لیے، سرورز کو
localhostپر بائنڈ کریں تاکہ انہیں عوامی انٹرنیٹ پر ایکسپوز ہونے سے بچایا جا سکے۔ - تصدیق: پروڈکشن ڈیپلائمنٹس کے لیے تصدیق (جیسے API کیز، OAuth) نافذ کریں۔
- CORS: کراس اورجن ریسورس شیئرنگ (CORS) پالیسیز کو ترتیب دیں تاکہ رسائی کو محدود کیا جا سکے۔
- HTTPS: پروڈکشن میں HTTPS استعمال کریں تاکہ ٹریفک کو انکرپٹ کیا جا سکے۔
مزید برآں، ایم سی پی اسٹریمنگ سرور میں سیکیورٹی نافذ کرتے وقت درج ذیل بہترین طریقوں پر عمل کریں:
- آنے والی درخواستوں پر بغیر توثیق کے بھروسہ نہ کریں۔
- تمام رسائی اور غلطیوں کو لاگ کریں اور مانیٹر کریں۔
- سیکیورٹی کی کمزوریوں کو دور کرنے کے لیے باقاعدگی سے ڈیپینڈنسیز کو اپ ڈیٹ کریں۔
ایم سی پی اسٹریمنگ سرورز میں سیکیورٹی نافذ کرتے وقت آپ کو کچھ چیلنجز کا سامنا ہوگا:
- ترقی کی آسانی کے ساتھ سیکیورٹی کا توازن برقرار رکھنا
- مختلف کلائنٹ ماحول کے ساتھ مطابقت کو یقینی بنانا
منظرنامہ: ایک ایم سی پی سرور اور کلائنٹ بنائیں جہاں سرور آئٹمز (مثلاً فائلز یا ڈاکیومنٹس) کی فہرست کو پروسیس کرے اور ہر پروسیس شدہ آئٹم کے لیے نوٹیفکیشن بھیجے۔ کلائنٹ کو ہر آنے والے نوٹیفکیشن کو ظاہر کرنا چاہیے۔
مراحل:
- ایک سرور ٹول نافذ کریں جو فہرست کو پروسیس کرے اور ہر آئٹم کے لیے نوٹیفکیشن بھیجے۔
- ایک کلائنٹ نافذ کریں جس میں ایک میسج ہینڈلر ہو جو نوٹیفکیشنز کو حقیقی وقت میں ظاہر کرے۔
- اپنے نفاذ کی جانچ کریں، سرور اور کلائنٹ دونوں کو چلا کر نوٹیفکیشنز کا مشاہدہ کریں۔
ایم سی پی اسٹریمنگ کے ساتھ اپنے سفر کو جاری رکھنے اور اپنے علم کو بڑھانے کے لیے، یہ سیکشن اضافی وسائل اور مزید جدید ایپلیکیشنز بنانے کے لیے تجویز کردہ اگلے اقدامات فراہم کرتا ہے۔
- Microsoft: HTTP اسٹریمنگ کا تعارف
- Microsoft: سرور-سینٹ ایونٹس (SSE)
- Microsoft: ASP.NET Core میں CORS
- Python requests: اسٹریمنگ ریکویسٹ
- مزید جدید ایم سی پی ٹولز بنانے کی کوشش کریں جو حقیقی وقت کے تجزیات، چیٹ، یا مشترکہ ایڈیٹنگ کے لیے اسٹریمنگ کا استعمال کریں۔
- حقیقی وقت کے یوزر انٹرفیس اپ ڈیٹس کے لیے ایم سی پی اسٹریمنگ کو فرنٹ اینڈ فریم ورکس (React, Vue وغیرہ) کے ساتھ ضم کرنے کا جائزہ لیں۔
- اگلا: VSCode کے لیے AI ٹول کٹ کا استعمال
ڈسکلیمر:
یہ دستاویز AI ترجمہ سروس Co-op Translator کا استعمال کرتے ہوئے ترجمہ کی گئی ہے۔ ہم درستگی کے لیے کوشش کرتے ہیں، لیکن براہ کرم آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا عدم درستگی ہو سکتی ہیں۔ اصل دستاویز، جو اس کی اصل زبان میں ہے، کو مستند ذریعہ سمجھا جانا چاہیے۔ اہم معلومات کے لیے، پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے لیے ہم ذمہ دار نہیں ہیں۔