البث عبر HTTPS باستخدام بروتوكول Model Context Protocol (MCP)

يوفر هذا الفصل دليلًا شاملاً لتنفيذ بث آمن وقابل للتوسع وفي الوقت الفعلي باستخدام بروتوكول Model Context Protocol (MCP) عبر HTTPS. يتناول الدوافع وراء البث، وآليات النقل المتاحة، وكيفية تنفيذ HTTP القابل للبث في MCP، وأفضل ممارسات الأمان، والانتقال من SSE، وإرشادات عملية لبناء تطبيقات MCP الخاصة بك.

آليات النقل والبث في MCP

تستكشف هذه القسم آليات النقل المختلفة المتاحة في MCP ودورها في تمكين قدرات البث للتواصل في الوقت الفعلي بين العملاء والخوادم.

ما هي آلية النقل؟

تعرف آلية النقل كيفية تبادل البيانات بين العميل والخادم. يدعم MCP أنواعًا متعددة من النقل لتناسب بيئات ومتطلبات مختلفة:

stdio: الإدخال/الإخراج القياسي، مناسب للأدوات المحلية والمبنية على CLI. بسيط ولكنه غير مناسب للويب أو السحابة.
SSE (Server-Sent Events): يسمح للخوادم بدفع التحديثات في الوقت الفعلي للعملاء عبر HTTP. جيد لواجهات المستخدم على الويب، ولكنه محدود من حيث التوسع والمرونة.
HTTP القابل للبث: نقل حديث قائم على HTTP يدعم الإشعارات وقابلية التوسع بشكل أفضل. موصى به لمعظم السيناريوهات الإنتاجية والسحابية.

جدول المقارنة

اطلع على جدول المقارنة أدناه لفهم الفروقات بين هذه الآليات:

النقل	التحديثات في الوقت الفعلي	البث	قابلية التوسع	حالة الاستخدام
stdio	لا	لا	منخفض	أدوات CLI المحلية
SSE	نعم	نعم	متوسط	الويب، التحديثات الفورية
HTTP القابل للبث	نعم	نعم	عالي	السحابة، العملاء المتعددون

نصيحة: اختيار النقل المناسب يؤثر على الأداء وقابلية التوسع وتجربة المستخدم. HTTP القابل للبث موصى به للتطبيقات الحديثة والقابلة للتوسع والمعدة للسحابة.

لاحظ النقلين stdio وSSE اللذين تم شرحهما في الفصول السابقة وكيف أن HTTP القابل للبث هو النقل الذي يتم تغطيته في هذا الفصل.

البث: المفاهيم والدوافع

فهم المفاهيم الأساسية والدوافع وراء البث ضروري لتنفيذ أنظمة اتصال فعالة في الوقت الفعلي.

البث هو تقنية في برمجة الشبكات تتيح إرسال واستقبال البيانات في أجزاء صغيرة ومدارة أو كسلسلة من الأحداث، بدلاً من انتظار استجابة كاملة لتكون جاهزة. هذا مفيد بشكل خاص لـ:

الملفات أو مجموعات البيانات الكبيرة.
التحديثات في الوقت الفعلي (مثل الدردشة، شريط التقدم).
العمليات الحسابية الطويلة التي تحتاج إلى إبقاء المستخدم على اطلاع.

إليك ما تحتاج إلى معرفته عن البث على مستوى عالٍ:

يتم تسليم البيانات تدريجيًا، وليس دفعة واحدة.
يمكن للعميل معالجة البيانات فور وصولها.
يقلل من زمن الانتظار المحسوس ويحسن تجربة المستخدم.

لماذا نستخدم البث؟

الأسباب لاستخدام البث هي كالتالي:

يحصل المستخدمون على ردود فعل فورية، وليس فقط في النهاية.
يتيح التطبيقات الفورية وواجهات المستخدم التفاعلية.
استخدام أكثر كفاءة لموارد الشبكة والحوسبة.

مثال بسيط: خادم HTTP للبث وعميل

إليك مثال بسيط على كيفية تنفيذ البث:

Python

الخادم (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())

يوضح هذا المثال خادمًا يرسل سلسلة من الرسائل إلى العميل فور توفرها، بدلاً من انتظار جميع الرسائل لتكون جاهزة.

كيف يعمل:

يقوم الخادم بإرسال كل رسالة فور جاهزيتها.
يستقبل العميل كل جزء ويطبعه فور وصوله.

المتطلبات:

يجب أن يستخدم الخادم استجابة بث (مثل StreamingResponse في FastAPI).
يجب أن يعالج العميل الاستجابة كبث (stream=True في requests).
عادةً ما يكون نوع المحتوى text/event-stream أو application/octet-stream.

Java

الخادم (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

يمكن توضيح الفروقات بين كيفية عمل البث "الكلاسيكي" وكيفية عمله في MCP كالتالي:

الميزة	البث الكلاسيكي عبر HTTP	البث في MCP (الإشعارات)
الاستجابة الرئيسية	مجزأة	واحدة، في النهاية
تحديثات التقدم	تُرسل كأجزاء بيانات	تُرسل كإشعارات
متطلبات العميل	يجب معالجة البث	يجب تنفيذ معالج رسائل
حالة الاستخدام	الملفات الكبيرة، تدفقات AI	التقدم، السجلات، ردود الفعل الفورية

الفروقات الرئيسية الملحوظة

إضافةً إلى ذلك، إليك بعض الفروقات الرئيسية:

نمط الاتصال:
- البث الكلاسيكي عبر HTTP: يستخدم ترميز نقل مجزأ بسيط لإرسال البيانات في أجزاء.
- البث في MCP: يستخدم نظام إشعارات منظم مع بروتوكول JSON-RPC.
تنسيق الرسائل:
- HTTP الكلاسيكي: أجزاء نصية عادية مع فواصل أسطر.
- MCP: كائنات LoggingMessageNotification منظمة مع بيانات وصفية.
تنفيذ العميل:
- HTTP الكلاسيكي: عميل بسيط يعالج استجابات البث.
- MCP: عميل أكثر تطورًا مع معالج رسائل لمعالجة أنواع مختلفة من الرسائل.
تحديثات التقدم:
- HTTP الكلاسيكي: التقدم جزء من تدفق الاستجابة الرئيسي.
- MCP: التقدم يُرسل عبر رسائل إشعار منفصلة بينما تأتي الاستجابة الرئيسية في النهاية.

التوصيات

هناك بعض التوصيات عند الاختيار بين تنفيذ البث الكلاسيكي (كنقطة نهاية أظهرناها أعلاه باستخدام /stream) مقابل اختيار البث عبر MCP.

للاحتياجات البسيطة للبث: البث الكلاسيكي عبر HTTP أبسط للتنفيذ وكافٍ للاحتياجات الأساسية.
للتطبيقات التفاعلية المعقدة: يوفر البث عبر MCP نهجًا أكثر تنظيمًا مع بيانات وصفية غنية وفصل بين الإشعارات والنتائج النهائية.
لتطبيقات الذكاء الاصطناعي: نظام الإشعارات في MCP مفيد بشكل خاص للمهام الطويلة حيث تريد إبقاء المستخدمين على اطلاع بالتقدم.

البث في MCP

حسنًا، لقد رأيت بعض التوصيات والمقارنات حتى الآن حول الفرق بين البث الكلاسيكي والبث في 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، تحتاج إلى إعداد كلا الجانبين، الخادم والعميل، للتعامل مع التحديثات في الوقت الفعلي. يسمح ذلك لتطبيقك بتقديم ردود فعل فورية للمستخدمين أثناء العمليات الطويلة.

جانب الخادم: إرسال الإشعارات

لنبدأ بجانب الخادم. في MCP، تقوم بتعريف الأدوات التي يمكنها إرسال الإشعارات أثناء معالجة الطلبات. يستخدم الخادم كائن السياق (عادةً ctx) لإرسال الرسائل إلى العميل.

Python

@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")

.NET

[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() لإرسال رسائل معلوماتية.

لتمكين الإشعارات في خادم MCP الخاص بـ .NET، تأكد من أنك تستخدم نقلًا قابلًا للبث:

var builder = McpBuilder.Create();
await builder
    .UseStreamableHttp() // Enable streamable HTTP transport
    .Build()
    .RunAsync();

جانب العميل: استقبال الإشعارات

يجب أن ينفذ العميل معالج رسائل لمعالجة الإشعارات وعرضها فور وصولها.

Python

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 للتعامل مع الإشعارات الواردة.

.NET

// 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، ولماذا هي مهمة، وكيفية تنفيذها باستخدام HTTP القابل للبث. ستجد أيضًا مهمة عملية لتعزيز فهمك.

إشعارات التقدم هي رسائل في الوقت الفعلي تُرسل من الخادم إلى العميل أثناء العمليات الطويلة. بدلاً من انتظار انتهاء العملية بالكامل، يقوم الخادم بإبقاء العميل محدثًا بالحالة الحالية. يحسن هذا الشفافية وتجربة المستخدم ويسهل التصحيح.

مثال:


"Processing document 1/10"
"Processing document 2/10"
...
"Processing complete!"

لماذا نستخدم إشعارات التقدم؟

إشعارات التقدم ضرورية لعدة أسباب:

تجربة مستخدم أفضل: يرى المستخدمون التحديثات أثناء تقدم العمل، وليس فقط في النهاية.
ردود فعل في الوقت الفعلي: يمكن للعملاء عرض أشرطة التقدم أو السجلات، مما يجعل التطبيق يبدو تفاعليًا.
تصحيح الأخطاء والمراقبة بسهولة: يمكن للمطورين والمستخدمين رؤية أين قد تكون العملية بطيئة أو متوقفة.

كيفية تنفيذ إشعارات التقدم

إليك كيفية تنفيذ إشعارات التقدم في MCP:

على الخادم: استخدم ctx.info() أو ctx.log() لإرسال الإشعارات أثناء معالجة كل عنصر. يرسل هذا رسالة إلى العميل قبل أن تكون النتيجة الرئيسية جاهزة.
على العميل: نفذ معالج رسائل يستمع للإشعارات ويعرضها فور وصولها. يميز هذا المعالج بين الإشعارات والنتيجة النهائية.

مثال على الخادم:

Python

@mcp.tool(description="A tool that sends progress notifications")
async def process_files(message: str, ctx: Context) -> TextContent:
    for i in range(1, 11):
        await ctx.info(f"Processing document {i}/10")
    await ctx.info("Processing complete!")
    return TextContent(type="text", text=f"Done: {message}")

مثال على العميل:

Python

async def message_handler(message):
    if isinstance(message, types.ServerNotification):
        print("NOTIFICATION:", message)
    else:
        print("SERVER MESSAGE:", message)

اعتبارات الأمان

عند تنفيذ خوادم MCP باستخدام وسائل نقل قائمة على HTTP، يصبح الأمان مصدر قلق بالغ يتطلب الانتباه إلى عدة نواقل هجوم وآليات حماية.

نظرة عامة

الأمان أمر بالغ الأهمية عند كشف خوادم MCP عبر HTTP. يقدم HTTP القابل للبث أسطح هجوم جديدة ويتطلب تكوينًا دقيقًا.

النقاط الرئيسية

التحقق من رأس Origin: تحقق دائمًا من رأس Origin لمنع هجمات إعادة الربط عبر DNS.
ربط Localhost: للتطوير المحلي، اربط الخوادم بـ localhost لتجنب كشفها على الإنترنت العام.
المصادقة: نفذ المصادقة (مثل مفاتيح API، OAuth) للنشر في الإنتاج.
CORS: قم بتكوين سياسات مشاركة الموارد عبر الأصل (CORS) لتقييد الوصول.
HTTPS: استخدم HTTPS في الإنتاج لتشفير حركة المرور.

أفضل الممارسات

لا تثق أبدًا في الطلبات الواردة دون التحقق.
قم بتسجيل ومراقبة جميع عمليات الوصول والأخطاء.
قم بتحديث التبعيات بانتظام لتصحيح الثغرات الأمنية.

التحديات

تحقيق التوازن بين الأمان وسهولة التطوير.
ضمان التوافق مع بيئات العملاء المختلفة.

الترقية من SSE إلى HTTP القابل للبث

بالنسبة للتطبيقات التي تستخدم حاليًا Server-Sent Events (SSE)، يوفر الانتقال إلى HTTP القابل للبث قدرات محسنة واستدامة أفضل على المدى الطويل لتنفيذات MCP.

لماذا الترقية؟

هناك سببان رئيسيان للترقية من SSE إلى Streamable HTTP:

يوفر Streamable HTTP قابلية توسع أفضل، وتوافقًا أوسع، ودعمًا أكثر ثراءً للإشعارات مقارنة بـ SSE.
يُوصى باستخدامه كوسيلة نقل للتطبيقات الجديدة التي تعتمد على MCP.

خطوات الترحيل

إليك كيفية الترحيل من SSE إلى Streamable HTTP في تطبيقات MCP الخاصة بك:

قم بتحديث كود الخادم لاستخدام transport="streamable-http" في mcp.run().
قم بتحديث كود العميل لاستخدام streamablehttp_client بدلاً من عميل SSE.
قم بتنفيذ معالج رسائل في العميل لمعالجة الإشعارات.
اختبر التوافق مع الأدوات وسير العمل الحالي.

الحفاظ على التوافق

يُوصى بالحفاظ على التوافق مع عملاء SSE الحاليين أثناء عملية الترحيل. إليك بعض الاستراتيجيات:

يمكنك دعم كل من SSE وStreamable HTTP عن طريق تشغيل كلا الوسيلتين على نقاط نهاية مختلفة.
قم بترحيل العملاء تدريجيًا إلى وسيلة النقل الجديدة.

التحديات

تأكد من معالجة التحديات التالية أثناء الترحيل:

ضمان تحديث جميع العملاء
التعامل مع الاختلافات في تسليم الإشعارات

اعتبارات الأمان

يجب أن تكون الأمان أولوية قصوى عند تنفيذ أي خادم، خاصة عند استخدام وسائل نقل تعتمد على HTTP مثل Streamable HTTP في MCP.

عند تنفيذ خوادم MCP باستخدام وسائل نقل تعتمد على HTTP، يصبح الأمان مصدر قلق بالغ يتطلب اهتمامًا دقيقًا بالعديد من نقاط الهجوم وآليات الحماية.

نظرة عامة

يُعد الأمان أمرًا بالغ الأهمية عند تعريض خوادم MCP عبر HTTP. يقدم Streamable HTTP أسطح هجوم جديدة ويتطلب تكوينًا دقيقًا.

فيما يلي بعض الاعتبارات الأمنية الرئيسية:

التحقق من رأس Origin: تحقق دائمًا من رأس Origin لمنع هجمات إعادة الربط عبر DNS.
الربط بـ Localhost: أثناء التطوير المحلي، اربط الخوادم بـ localhost لتجنب تعريضها للإنترنت العام.
المصادقة: قم بتنفيذ المصادقة (مثل مفاتيح API، OAuth) للنشر في بيئات الإنتاج.
CORS: قم بتكوين سياسات مشاركة الموارد عبر الأصل (CORS) لتقييد الوصول.
HTTPS: استخدم HTTPS في بيئات الإنتاج لتشفير حركة المرور.

أفضل الممارسات

بالإضافة إلى ذلك، إليك بعض أفضل الممارسات التي يجب اتباعها عند تنفيذ الأمان في خادم MCP للبث:

لا تثق أبدًا في الطلبات الواردة دون التحقق منها.
قم بتسجيل ومراقبة جميع عمليات الوصول والأخطاء.
قم بتحديث التبعيات بانتظام لتصحيح الثغرات الأمنية.

التحديات

ستواجه بعض التحديات عند تنفيذ الأمان في خوادم MCP للبث:

تحقيق التوازن بين الأمان وسهولة التطوير
ضمان التوافق مع بيئات العملاء المختلفة

المهمة: بناء تطبيق MCP للبث الخاص بك

السيناريو: قم ببناء خادم وعميل MCP حيث يقوم الخادم بمعالجة قائمة من العناصر (مثل الملفات أو المستندات) ويرسل إشعارًا لكل عنصر يتم معالجته. يجب أن يعرض العميل كل إشعار بمجرد وصوله.

الخطوات:

قم بتنفيذ أداة خادم تعالج قائمة وترسل إشعارات لكل عنصر.
قم بتنفيذ عميل بمعالج رسائل لعرض الإشعارات في الوقت الفعلي.
اختبر تنفيذك عن طريق تشغيل كل من الخادم والعميل، وراقب الإشعارات.

الحل

المزيد من القراءة وما التالي؟

لمواصلة رحلتك مع بث MCP وتوسيع معرفتك، يوفر هذا القسم موارد إضافية وخطوات مقترحة لبناء تطبيقات أكثر تقدمًا.

ما التالي؟

حاول بناء أدوات MCP أكثر تقدمًا تستخدم البث لتحليلات الوقت الفعلي، أو الدردشة، أو التحرير التعاوني.
استكشف دمج بث MCP مع أطر العمل الأمامية (React، Vue، إلخ) لتحديثات واجهة المستخدم الحية.
التالي: استخدام أدوات الذكاء الاصطناعي لـ VSCode

إخلاء المسؤولية:
تم ترجمة هذا المستند باستخدام خدمة الترجمة الآلية Co-op Translator. بينما نسعى لتحقيق الدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو عدم دقة. يجب اعتبار المستند الأصلي بلغته الأصلية هو المصدر الموثوق. للحصول على معلومات حساسة أو هامة، يُوصى بالاستعانة بترجمة بشرية احترافية. نحن غير مسؤولين عن أي سوء فهم أو تفسيرات خاطئة تنشأ عن استخدام هذه الترجمة.

FilesExpand file tree

README.md

Latest commit

History

README.md

File metadata and controls

البث عبر HTTPS باستخدام بروتوكول Model Context Protocol (MCP)

آليات النقل والبث في MCP

ما هي آلية النقل؟

جدول المقارنة

البث: المفاهيم والدوافع

لماذا نستخدم البث؟

مثال بسيط: خادم HTTP للبث وعميل

Python

Java

مقارنة: البث الكلاسيكي مقابل البث في MCP

الفروقات الرئيسية الملحوظة

التوصيات

البث في MCP

كيف يعمل

ما هي الإشعارات؟

تنفيذ الإشعارات في MCP

جانب الخادم: إرسال الإشعارات

Python

.NET

جانب العميل: استقبال الإشعارات

Python

.NET

إشعارات التقدم والسيناريوهات

لماذا نستخدم إشعارات التقدم؟

كيفية تنفيذ إشعارات التقدم

Python

Python

اعتبارات الأمان

نظرة عامة

النقاط الرئيسية

أفضل الممارسات

التحديات

الترقية من SSE إلى HTTP القابل للبث

لماذا الترقية؟

خطوات الترحيل

الحفاظ على التوافق

التحديات

اعتبارات الأمان

نظرة عامة

أفضل الممارسات

التحديات

المهمة: بناء تطبيق MCP للبث الخاص بك

المزيد من القراءة وما التالي؟

المزيد من القراءة

ما التالي؟