microsoft--mcp-for-beginners/translations/km/03-GettingStarted/06-http-streaming/README.md

HTTPS Streaming ជាមួយនឹង Model Context Protocol (MCP)

ជំពូកនេះផ្តល់ជាមគ្គុទេសក៍ដ៏មានសកម្មភាពសម្រាប់អនុវត្តស្ដ្រីមមីងដែលមានសុវត្ថិភាព អាចពង្រីកបាន និងពេលត្រង់ជាមួយ Model Context Protocol (MCP) ដោយប្រើ HTTPS។ វាគ្របដណ្តប់ពីហេតុផលសម្រាប់ស្ដ្រីមមីង មធ្យោបាយដឹកជញ្ជូនដែលអាចប្រើបាន របៀបអនុវត្ត HTTP ដែលអាចស្ដ្រីមមីងបានក្នុង MCP ការអនុវត្តល្អបំផុត សម្រាប់ការផ្លាស់ប្តូរពី SSE និងមគ្គុទេសក៍ផ្នែកជាក់លាក់សម្រាប់កសាងកម្មវិធី MCP ស្ដ្រីមមីងរបស់អ្នកផ្ទាល់។

មធ្យោបាយដឹកជញ្ជូន និង ស្ដ្រីមមីង ក្នុង MCP

អំពើនេះស្វែងយល់អំពីមធ្យោបាយដឹកជញ្ជូនផ្សេងៗដែលអាចប្រើបានក្នុង MCP និងតួនាទីរបស់ពួកវាក្នុងការអនុញ្ញាតឲ្យមានសមត្ថភាពស្ដ្រីមមីងសម្រាប់ការទំនាក់ទំនងពេលត្រង់រវាងអតិថិជន និងម៉ាស៊ីនបម្រើ។

មធ្យោបាយដឹកជញ្ជូនជាអ្វី?

មធ្យោបាយដឹកជញ្ជូនកំណត់ពីរបៀបដែលទិន្នន័យត្រូវបានប្ដូរគ្នារវាងអតិថិជន និងម៉ាស៊ីនបម្រើ។ MCP គាំទ្រមធ្យោបាយដឹកជញ្ជូនជាច្រើនដើម្បីឆបគ្នានឹងបរិយាកាសនិងតម្រូវការផ្សេងៗ៖

• stdio: ឧបករណ៍បញ្ចូល/បញ្ចេញស្តង់ដារ, សាកសមសម្រាប់ឧបករណ៍ក្នុងតំបន់ និង CLI។ សាមញ្ញ ប៉ុន្តែមិនសមសម្រាប់បណ្តាញឬពពក។
• SSE (Server-Sent Events): អនុញ្ញាតឲ្យម៉ាស៊ីនបម្រើបញ្ចូនបច្ចុប្បន្នភាពពេលត្រង់ទៅអតិថិជនតាម HTTP។ ល្អសម្រាប់ UI វេប ប៉ុន្តេលំបាកក្នុងការពង្រីក និងអាចបត់បែនបាន។ ចាប់តាំងពី MCP Specification 2025-06-18 មធ្យោបាយដឹកជញ្ជូន SSE ឯករាជ្យត្រូវបានលុបចោល និងជំនួសដោយ "Streamable HTTP"។
• Streamable HTTP: មធ្យោបាយស្ដ្រីមមីងទៅលើ HTTP សម្រេចបានល្អ ឆ្លើយតប Notification និងពង្រីកបានល្អ។ ប្រាប់សម្រាប់ករណីផលិតកម្ម និងពពកភាគច្រើន។

តារាងតុល្យភាព

សូមមើលតារាងតុល្យភាពខាងក្រោមដើម្បីយល់ពីភាពខុសគ្នារវាងមធ្យោបាយដឹកជញ្ជូនទាំងនេះ៖

មធ្យោបាយដឹកជញ្ជូន	បច្ចុប្បន្នភាពពេលត្រង់	ស្ដ្រីមមីង	ភាពអាចពង្រីកបាន	ករណីប្រើប្រាស់
stdio	ទេ	ទេ	ទាប	ឧបករណ៍ CLI ក្នុងតំបន់
SSE	បាទ	បាទ	មធ្យម	វេប ការបច្ចុប្បន្នភាពពេលត្រង់
Streamable HTTP	បាទ	បាទ	ខ្ពស់	ពពក អតិថិជនច្រើន

ចំណាំ: ការជ្រើសរើសមធ្យោបាយដឹកជញ្ជូនត្រឹមត្រូវប៉ះពាល់ដល់ប្រសិទ្ធភាព ភាពអាចពង្រីកបាន និងបទពិសោធន៍អ្នកប្រើ។ Streamable HTTP ត្រូវបានផ្តល់អនុសាសន៍សម្រាប់កម្មវិធីទំនើប អាចពង្រីក និងសាកសមសម្រាប់ពពក។

ចំណាំពីមធ្យោបាយ stdio និង SSE ដែលអ្នកបានមើលនៅជំពូកមុន ហើយរបៀបដែល Streamable HTTP គឺជាមធ្យោបាយដែលបានរៀបរាប់នៅជំពូកនេះ។

ស្ដ្រីមមីង៖ គំនិត និងហេតុផល

ការយល់ដឹងអំពីគំនិតមូលដ្ឋាន និងហេតុផលនៅពីក្រោយស្ដ្រីមមីងគឺសំខាន់សម្រាប់អនុវត្តប្រព័ន្ធទំនាក់ទំនងពេលត្រង់ដែលមានប្រសិទ្ធភាព។

ស្ដ្រីមមីង គឺជាជំនាញក្នុងកម្មវិធីបណ្តាញដែលអនុញ្ញាតឲ្យទិន្នន័យត្រូវបានផ្ញើ និងទទួលក្នុងចំណែកតូចៗ ងាយគ្រប់គ្រង ឬជាខ្សែឈរ (sequence) នៃព្រឹត្តិការណ៍ ជំនួសការរំពឹងរង់ចាំការឆ្លើយតបពេញលេញ។ នេះមានប្រយោជន៍ជាពិសេសសម្រាប់៖

• ឯកសារឥកចតធំនិងសំណុំទិន្នន័យធំ។
• បច្ចុប្បន្នភាពពេលត្រង់ (ដូចជាការជជែក ព្រឹត្តិបទចលនា)។
• ការគណនាយូរអង្វែងដែលអ្នកចង់ពាក់ព័ន្ធអ្នកប្រើ។

នេះជាអ្វីដែលអ្នកត្រូវដឹងអំពីស្ដ្រីមមីងនៅកម្រិតខ្ពស់៖

• ទិន្នន័យត្រូវបានផ្តល់ជាជំហ៊ាន ជាបន្តបន្ទាប់ មិនមែនមួយទឹកទាំងអស់។
• អតិថិជនអាចដំណើរការទិន្នន័យនៅពេលវាចូល។
• កាត់បន្ថយពេលលៃតម្រូវ និងបង្កើនបទពិសោធន៍អ្នកប្រើ។

ហេតុអ្វីបានជាអ្នកប្រើស្ដ្រីមមីង?

ហេតុនេះដែលហើយទេជាជម្រើសស្ដ្រីមមីងមានដូចជា៖

• អ្នកប្រើទទួលបានមតិយោបល់ភ្លាមៗ មិនមែនរង់ចាំជាមួយចុងក្រោយទេ
• អនុញ្ញាតកម្មវិធីពេលត្រង់ និង UI ឆ្លើយតប
• ប្រើប្រាស់ធនធានបណ្តាញ និងគណនាកាន់តែល្អប្រសើរ

ឧទាហរណ៍សាមញ្ញ៖ ម៉ាស៊ីនបម្រើ & អតិថិជន HTTP Streaming

នេះជាឧទាហរណ៍សាមញ្ញនៃរបៀបស្ដ្រីមមីងអាចអនុវត្តបាន៖

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។
• អតិថិជនត្រូវដំណើរការឆ្លើយតបជា stream (stream=True ក្នុង requests)។
• Content-Type ជាទូទៅគឺ 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 រចនាសម្ព័ន្ធ reactive ជាមួយ Flux សម្រាប់ស្ដ្រីមមីង
• ServerSentEvent ផ្តល់ស្ទ្រីមមីងព្រឹត្តិការណ៍ដែលមានរចនាសម្ព័ន្ធជាមួយប្រភេទព្រឹត្តិការណ៍
• WebClient ជាមួយ bodyToFlux() អនុញ្ញាតដំណើរការស្ដ្រីមមីង reactive
• delayElements() ភាគន័យចំណាយពេលចន្លោះព្រឹត្តិការណ៍
• ព្រឹត្តិការណ៍អាចមានប្រភេទ (info, result) សម្រាប់ដំណើរការល្អប្រសើរអតិថិជន

តុល្យភាព៖ ស្ដ្រីមមីងបែបបុរាណនិងស្ដ្រីមមីង MCP

ភាពខុសគ្នារវាងរបៀបស្ដ្រីមមីងបែប "បុរាណ" និងរបៀបស្ដ្រីមមីង MCP អាចបង្ហាញដូចជា៖

លក្ខណៈ	ស្ដ្រីមមីង HTTP បុរាណ	ស្ដ្រីមមីង MCP (ជូនដំណឹង)
ចម្លើយសំខាន់	ភាគតូច	តែមួយនៅចុង
បច្ចុប្បន្នភាព	ផ្ញើជាផ្នែកទិន្នន័យ	ផ្ញើជាជូនដំណឹង
តម្រូវការអតិថិជន	ត្រូវដំណើរការស្ដ្រីមីង	ត្រូវអនុវត្តមេកានីសំរាប់ជំនួយសារ
ករណីប្រើប្រាស់	ឯកសារធំ, ស្ដ្រីមីង token AI	ចំណុចប្រមុខ កំណត់ហេតុ និងមតិយោបល់ពេលត្រង់

ភាពខុសគ្នាសំខាន់ៗដែលបានសង្កេត

បន្ថែមពីនេះ មានភាពខុសគ្នាសំខាន់ៗដូចជា៖

• លំនាំទំនាក់ទំនង៖

  • ស្ដ្រីមមីង HTTP បុរាណ៖ ប្រើ chunked transfer encoding ពិសេសសម្រាប់ផ្ញើទិន្នន័យជាចំណែក
  • ស្ដ្រីមមីង MCP៖ ប្រើប្រព័ន្ធជូនដំណឹងមានរចនាសម្ព័ន្ធជាមួយប្រព័ន្ធ JSON-RPC

• ទ្រង់ទ្រាយសារ៖

  • HTTP បុរាណ៖ ផ្នែកអត្ថបទរាបស្មើមាន newlines
  • MCP៖ ផ្នែក LoggingMessageNotification ដែលមានរចនាសម្ព័ន្ធ និងភាគីក្រៅ

• ការអនុវត្តអតិថិជន៖

  • HTTP បុរាណ៖ អតិថិជនសាមញ្ញដំណើរការឆ្លើយតបស្ដ្រីមមីង
  • MCP៖ អតិថិជនមានការត្រួតពិនិត្យជាមេកានីសំរាប់ដំណើរការសារផ្សេងគ្នា

• បច្ចុប្បន្នភាព៖

  • HTTP បុរាណ៖ បច្ចុប្បន្នភាពជាផ្នែកនៃចម្លើយសំខាន់
  • MCP៖ បច្ចុប្បន្នភាពផ្ញើជាផ្សេងពីការជូនដំណឹង ខណៈពេលចម្លើយសំខាន់ផ្ញើនៅចុង

ការផ្តល់អនុសាសន៍

មានអ្វីខ្លះដែលយើងផ្តល់អនុសាសន៍ពេលជ្រើសរើសរវាងការអនុវត្តស្ដ្រីមមីងបែបបុរាណ (ជាចំណុចចុងដែលបានបង្ហាញ /stream) ឬជ្រើសរើសស្ដ្រីមមីងតាម MCP៖

• សម្រាប់តម្រូវការស្ដ្រីមមីងសាមញ្ញ៖ ស្ដ្រីមមីង HTTP បែបបុរាណសាមញ្ញក្នុងការអនុវត្តនិងគ្រប់គ្រាន់សម្រាប់តម្រូវការសាមញ្ញ។

• សម្រាប់កម្មវិធីស្មុគស្មាញ និងអន្តរកម្ម៖ ស្ដ្រីមមីង MCP ផ្តល់របៀបមានរចនាសម្ព័ន្ធ និងមានផ្នែកពាណិជ្ជកម្មតូចធំរវាងជូនដំណឹង និងលទ្ធផលចុងក្រោយ។

• សម្រាប់កម្មវិធី AI៖ ប្រព័ន្ធជូនដំណឹង MCP មានប្រយោជន៍ពិសេសសម្រាប់ភារកិច្ច AI យូរអង្វែងដែលអ្នកចង់ឲ្យអ្នកប្រើបានដឹងពីចំណុចប្រមុខ។

ស្ដ្រីមមីងក្នុង MCP

បានហើយ អ្នកបានឃើញអនុសាសន៍ និងការតុល្យភាពរវាងស្ដ្រីមមីងបែបបុរាណ និងស្ដ្រីមមីង MCP។ ឥឡូវចូលទៅលម្អិតរបៀបដែលអ្នកអាចប្រើប្រាស់ស្ដ្រីមមីងក្នុង MCP។

ការយល់ដឹងពីរបៀបស្ដ្រីមមីងដំណើរការនៅក្នុងស៊ុម MCP គឺមុខមួយសំខាន់សម្រាប់ការកសាងកម្មវិធីឆ្លើយតបដែលផ្តល់មតិយោបល់ពេលត្រង់ដល់អ្នកប្រើក្នុងអំឡុងពេលប្រតិបត្តិការយូរអង្វែង។

នៅក្នុង MCP ស្ដ្រីមមីងមិនមែនបញ្ជូនចម្លើយសំខាន់ជាចំណែកៗទេ តែបញ្ជូន ជូនដំណឹង ទៅអតិថិជន ខណៈឧបករណ៍កំពុងដំណើរការសំណើ។ ជូនដំណឹងទាំងនេះអាចរួមបញ្ចូលបច្ចុប្បន្នភាព កំណត់ហេតុ ឬព្រឹត្តិការណ៍ផ្សេងៗ។

របៀបដែលវាដំណើរការ

លទ្ធផលសំខាន់នៅតែបញ្ជូនជាចម្លើយមួយយ៉ាងស្រួល។ ទោះជាយ៉ាងណា ជូនដំណឹងអាចបញ្ជូនជាសារផ្សេងក្នុងអំឡុងពេលដំណើរការ ហើយធ្វើការកែប្រែអតិថិជនជាពេលត្រង់។ អតិថិជនត្រូវតែអាចដំណើរការបាន និងបង្ហាញជូនដំណឹងទាំងនេះ។

ជូនដំណឹងជាអ្វី?

យើងបាននិយាយថា "ជូនដំណឹង" មានអត្ថន័យអ្វីនៅក្នុងបរិបទ MCP?

ជូនដំណឹងគឺជាសារ ដែលផ្ញើពីម៉ាស៊ីនបម្រើទៅអ្នកប្រើ ដើម្បីជូនដំណឹងអំពីចំណុចប្រមុខ ស្ថានភាព ឬព្រឹត្តិការណ៍ផ្សេងៗនៅក្នុងអំឡុងពេលប្រតិបត្តិការយូរអង្វែង។ ជូនដំណឹងបង្កើនភាពបញ្ចាក់ និងបទពិសោធន៍អ្នកប្រើ។

ឧទាហរណ៍ អតិថិជនគួរផ្ញើជូនដំណឹងមួយនៅពេលបញ្ចប់ការប្រលងលើកដំបូងជាមួយម៉ាស៊ីនបម្រើ។

ជូនដំណឹងមើលទៅដូចសារចម្រុះ JSON៖

{
  jsonrpc: "2.0";
  method: string;
  params?: {
    [key: string]: unknown;
  };
}

ជូនដំណឹងទាក់ទងនឹងប្រធានបទនៅក្នុង MCP ដែលហៅថា "Logging"។

ដើម្បីធ្វើឲ្យ logging ដំណើរការ ម៉ាស៊ីនបម្រើត្រូវសកម្មវាពិគ្រោះជាលក្ខណៈលក្ខណៈពិសេស/មុខងារដូចខាងក្រោម៖

{
  "capabilities": {
    "logging": {}
  }
}

Note

អាស្រ័យលើយូធីលមួយ (SDK) ផ្សេងៗ logging ប្រហែលត្រូវបានដំណើរការដោយឥតគិតថ្លៃ ឬ អ្នកអាចត្រូវការសកម្មវាងោលសម្រាប់វាក្នុងការកំណត់ផ្នែកម៉ាស៊ីនបម្រើរបស់អ្នក។

មានប្រភេទជូនដំណឹងផ្សេងៗគ្នា៖

កម្រិត	ការពិពណ៌នា	ករណីប្រើប្រាស់ឧទាហរណ៍
debug	ព័ត៌មាន debugging លំអិត	ចំណុចចូល/ចេញមុខងារ
info	សារ​ព័ត៌មានទូទៅ	ការអាប់ដេតចំណុចប្រមុខ
notice	ព្រឹត្តិការណ៍ធម្មតាប៉ុន្តែសំខាន់	ការផ្លាស់ប្តូរការកំណត់
warning	គ្រោះថ្នាក់​ថ្នាក់	ការប្រើមុខងារដែលត្រូវលុបចោល
error	កំហុស	ការបរាជ័យប្រតិបត្តិការ
critical	លំបាក	ការបរាជ័យផ្នែកប្រព័ន្ធ
alert	ត្រូវអនុវត្តសកម្មភាពភ្លាមៗ	ការរងគ្រោះភាពខូចខាតបញ្ចេញ
emergency	ប្រព័ន្ធមិនអាចប្រើបាន	បម្រែបម្រួលប្រព័ន្ធសរុប

ការអនុវត្តជូនដំណឹងក្នុង MCP

ក្នុងការអនុវត្តជូនដំណឹងក្នុង MCP អ្នកត្រូវតែសម្ភោធម្ខាងម៉ាស៊ីនបម្រើ និងម្ខាងអតិថិជនដើម្បីដំណើរការបច្ចុប្បន្នភាពពេលត្រង់។ នេះឲ្យកម្មវិធីរបស់អ្នកផ្តល់មតិយោបល់ភ្លាមៗទៅអ្នកប្រើក្នុងអំឡុងពេលប្រតិបត្តិការ​យូរសង្ខេប។

មុខម៉ាស៊ីនបម្រើ៖ ផ្ញើជូនដំណឹង

ចាប់ផ្តើមពីម្ខាងម៉ាស៊ីនបម្រើ។ នៅក្នុង MCP អ្នកកំណត់ឧបករណ៍ដែលអាចផ្ញើជូនដំណឹងខណៈកំពុងដំណើរការសំណើ។ ម៉ាស៊ីនបម្រើប្រើវត្ថុ context (ជាទូទៅគឺ 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, ហេតុអ្វីបានជាវាគឺសំខាន់ និងរបៀបអនុវត្តវា ដោយប្រើ Streamable 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។ Streamable HTTP បញ្ចូលផ្ទៃវាយកម្ទេចថ្មីៗ ហើយត្រូវការការកំណត់យ៉ាងតឹងរឹង។

ចំណុចសំខាន់ៗ

• ការផ្ទៀងផ្ទាត់ Origin Header: តែងតែផ្ទៀងផ្ទាត់ក្បាល Origin ដើម្បីបញ្ឈប់ការវាយកម្ទេចប្រភព DNS។
• ការចងខ្សែ Localhost: សម្រាប់ការអភិវឌ្ឍន៍ក្នុងតំបន់ ចងខ្សែម៉ាស៊ីនបម្រើទៅ localhost ដើម្បីកុំឲ្យបង្ហាញវាទៅអ៊ីនធឺណិតសាធារណៈ។
• ការផ្ទៀងផ្ទាត់អត្តសញ្ញាណ: អនុវត្តការផ្ទៀងផ្ទាត់ (ដូចជា កូនសោ API, OAuth) សម្រាប់ការតំឡើងផលិតកម្ម។
• CORS: កំណត់គោលការណ៍ផ្នែក Cross-Origin Resource Sharing (CORS) ដើម្បីដាក់កំណត់ការចូលដំណើរការ។
• HTTPS: ប្រើ HTTPS ក្នុងផលិតកម្មដើម្បីបំបែកព័ត៌មាតិចចរាចរណ៍។

អនុវត្តល្អបំផុត

• កុំជឿទុកលើសំណើដែលមិនបានផ្ទៀងផ្ទាត់។
• កត់ត្រា និងត្រួតពិនិត្យការចូលដំណើរការ និងកំហុសទាំងអស់។
• ធ្វើបច្ចុប្បន្នភាពផ្នែកខាងក្រៅជាផ្លូវការយ៉ាងទៀងទាត់ដើម្បីជួសជុលចំហច្របល់សុវត្ថិភាព។

챌린ជ៏

• ធ្វើឲ្យសមតុល្យរវាងសុវត្ថិភាព និងភាពងាយស្រួលក្នុងការអភិវឌ្ឍ
• ដើម្បីធានាថាមានការភាពសមរម្យជាមួយបរិយាកាសកម្មវិធីអតិថិជនផ្សេងៗ

ការអាប់ហ្រ្វេតពី SSE មក Streamable HTTP

សម្រាប់កម្មវិធីដែលកំពុងប្រើប្រាស់ Server-Sent Events (SSE) ការបម្លែងទៅ Streamable HTTP នឹងផ្តល់នូវសមត្ថភាពប្រសើរឡើង និងភាពច្នៃប្រឌិតបន្ថែមសម្រាប់ការអនុវត្ត MCP របស់អ្នកឲ្យមានភាពរីកចម្រើនរយៈពេលវែង។

ហេតុផលក្នុងការអាប់ហ្រ្វេត?

មានហេតុផលចាំបាច់ពីរដើម្បីអាប់ហ្រ្វេតពី SSE ទៅ Streamable HTTP៖

• Streamable HTTP ផ្តល់នូវភាពលូតលាស់ប្រសើរ ជាការសមរម្យ និងការប្រកួតប្រជែងដែលមានស្បែករឹងជាង SSE។
• វាជារបៀបដឹកជញ្ជូនដែលបានណែនាំសម្រាប់កម្មវិធី MCP ថ្មីៗ។

ជំហានក្នុងការផ្លាស់ប្តូរ

នេះជាវិធីដែលអ្នកអាចផ្លាស់ប្តូរពី SSE ទៅ Streamable HTTP ក្នុងកម្មវិធី MCP របស់អ្នក៖

• អាប់ហ្រ្វេតកូដម៉ាស៊ីនមេ ដើម្បីប្រើ transport="streamable-http" ក្នុង mcp.run()។
• អាប់ហ្រ្វេតកូដអតិថិជន ដើម្បីប្រើ streamablehttp_client ជំនួស SSE client។
• អនុវត្តកម្មវិធីដោះលេខសារមួយ ក្នុងអតិថិជនដើម្បីដំណើរការជូនដំណឹង។
• សាកល្បងសមរម្យភាព ជាមួយឧបករណ៍ និងដំណើរការដែលមានរួច។

រក្សាសមរម្យភាព

បានណែនាំឲ្យរក្សាសមរម្យភាពជាមួយអតិថិជន SSE ដែលមានរួចក្នុងអំឡុងការផ្លាស់ប្តូរ។ ខាងក្រោមជាការ្យយុទ្ធខ្លះៗ៖

• អ្នកអាចគាំទ្រទាំង SSE និង Streamable HTTP ដោយរត់ការដឹកជញ្ជូនទាំងពីរនៅចំណុចចូលផ្សេងៗគ្នា។
• ផ្លាស់ប្តូរអតិថិជនទៅកាន់របៀបដឹកជញ្ជូនថ្មីយ៉ាងត្រជាក់ត្រជម។

បញ្ហារ

ត្រូវធានាថាអ្នកដោះស្រាយបញ្ហាខាងក្រោមក្នុងអំឡុងការផ្លាស់ប្តូរ៖

• ប្តូរអតិថិជនទាំងអស់
• ដោះស្រាយភាពខុសគ្នានៃការដឹកជញ្ជូនការជូនដំណឹង

ការពិចារណាសុវត្ថិភាព

សុវត្ថិភាពគួរតែជាប្រធានបទសំខាន់បំផុតនៅពេលបង្កើតម៉ាស៊ីនមេណាមួយ ជាពិសេសនៅពេលប្រើប្រាស់របៀបដឹកជញ្ជូនផ្អែកលើ HTTP ដូចជា Streamable HTTP ក្នុង MCP។

ពេលដែលអនុវត្តម៉ាស៊ីនមេ MCP ជាមួយរបៀបដឹកជញ្ជូនផ្អែកលើ HTTP សុវត្ថិភាពក្លាយជាបញ្ហាសំខាន់ណាស់ដែលត្រូវបានយកចិត្តទុកដាក់យ៉ាងប្រាកដល្អចំពោះវ៉ិចទ័រការវាយប្រហារផ្សេងៗ និងមេកានិចការពារ។

សង្ខេប

សុវត្ថិភាពគឺសំខាន់ណាស់នៅពេលដែលបង្ហាញម៉ាស៊ីនមេ MCP តាមរយៈ HTTP។ Streamable HTTP អនុញ្ញាតឲ្យមានផ្ទៃប្រយោជន៍វាយប្រហារថ្មី និងត្រូវការការកំណត់រចនាប័ទ្មយ៉ាងម៉ត់ចត់។

នេះជាការពិចារណាសុវត្ថិភាពសំខាន់ៗ៖

• ការ​ផ្ទៀងផ្ទាត់ក្បាល Origin៖ ត្រូវតែផ្ទៀងផ្ទាត់ក្បាល Origin ជានិរន្តរ ដើម្បីការពារការវាយប្រហារដូចជា DNS rebinding។
• ចងក្រង localhost៖ សម្រាប់ការអភិវឌ្ឍនៅក្នុងផ្ទះ ទំនាក់ទំនងម៉ាស៊ីនមេទៅ localhost ដើម្បីកុំឲ្យមានការបង្ហាញទៅអ៊ីនធឺណិតសាធារណៈ។
• ការផ្ទៀងផ្ទាត់អត្តសញ្ញាណ៖ អនុវត្តផ្ទៀងផ្ទាត់អត្តសញ្ញាណ (ដូចជា កូនសោ API, OAuth) សម្រាប់ការចេញផ្សាយលើផលិតកម្ម។
• CORS៖ កំណត់គោលការណ៍ការចូលដំណើរការឆ្លង-Origin (CORS) ដើម្បីកំណត់សិទ្ធិ។
• HTTPS៖ ប្រើ HTTPS នៅក្នុងផលិតកម្មដើម្បីបង្ការជ្រេីសទិន្នន័យ។

របៀបអនុវត្តល្អបំផុត

ក្រៅពីនេះ នេះជារបៀបល្អបំផុតដែលគួរអនុវត្តនៅពេលផ្តល់សុវត្ថិភាពនៅម៉ាស៊ីនមេស្ទ្រីម MCP របស់អ្នក៖

• មិនគួរឱ្យទុកចិត្តសំណើដែលចូលមកក្រៅពីការផ្ទៀងផ្ទាត់ឡើយ។
• កត់ត្រានិងមើលការចូលប្រើនិងកំហុសទាំងអស់។
• កែប្រែផ្នែកជំនួយជាប្រចាំដើម្បីជួសជុលចំនុចខ្សោយសុវត្ថិភាព។

បញ្ហារ

អ្នកនឹងប្រឈមមុខនឹងបញ្ហាគ្រប់ប្រភេទពេលអនុវត្តសុវត្ថិភាពនៅម៉ាស៊ីនមេស្ទ្រីម MCP៖

• ធ្វើឲ្យសមតុល្យរវាងសុវត្ថិភាព និងភាពងាយស្រួលក្នុងការអភិវឌ្ឍ
• ការធានាសមរម្យភាពជាមួយបរិយាកាសកម្មវិធីអតិថិជនផ្សេងៗ

ភារកិច្ច៖ បង្កើតកម្មវិធី MCP Streaming របស់អ្នកឯង

ស្ថានភាព៖ បង្កើតម៉ាស៊ីនមេ MCP និងអតិថិជនដែលម៉ាស៊ីនមេដំណើរការបញ្ជីធាតុ (ដូចជា ឯកសារ ឬឯកសារសរសេរ) ហើយផ្ញើជូនដំណឹងសម្រាប់រាល់ធាតុដែលបានដំណើរការ។ អតិថិជនគួរតែបង្ហាញជូនដំណឹងនីមួយៗនៅពេលវាចូល។

ជំហាន៖

1. អនុវត្តឧបករណ៍ម៉ាស៊ីនមេដែលដំណើរការបញ្ជី ហើយផ្ញើជូនដំណឹងសម្រាប់រាល់ធាតុ។
2. អនុវត្តអតិថិជនដែលមានកម្មវិធីដោះលេខសារដើម្បីបង្ហាញជូនដំណឹងដំបូងៗ។
3. សាកល្បងការអនុវត្តដោយរត់ម៉ាស៊ីនមេ និងអតិថិជន ហើយមើលជូនដំណឹង។

Solution

អានបន្ថែម និង តើបន្ទាប់មក?

ដើម្បីបន្តដំណើររបស់អ្នកជាមួយស្ទ្រីមមីង MCP និងពង្រីកចំណេះ ដេីម្បីជួយឲ្យបង្កើតកម្មវិធីកម្រិតខ្ពស់ជាងនេះ ផ្នែកនេះផ្តល់ធនធានបន្ថែម និងដំណើរការណាមួយដែលបានណែនាំសម្រាប់ការបន្ត។

អានបន្ថែម

• Microsoft: ការណែនាំអំពី HTTP Streaming
• Microsoft: Server-Sent Events (SSE)
• Microsoft: CORS ក្នុង ASP.NET Core
• Python requests: Streaming Requests

តើបន្ទាប់?

• ព្យាយាមបង្កើតឧបករណ៍ MCP កម្រិតខ្ពស់ដែលប្រើស្ទ្រីមមីងសម្រាប់វិភាគពេលវេលាពិត បន្ទប់សន្ទនា ឬកែប្រែរួមគ្នា។
• ស្វែងយល់ការបញ្ចូល MCP streaming ជាមួយគំរូមុខងារបង្ហាញមុខ (React, Vue, ល។) សម្រាប់អាប់ដេត UI ពេលវេលាពិត។
• បន្ទាប់: ការប្រើ AI Toolkit សម្រាប់ VSCode

---

ការបដិសេធ: ឯកសារនេះត្រូវបានបម្លែងភាសា ដោយប្រើសេវាបម្លែងភាសា AI Co-op Translator។ ទោះយើងខ្ញុំមានក្តីប្រាថ្នាឱ្យបានច្បាស់លាស់ តែសូមយល់ដឹងថាការបម្លែងដោយស្វ័យប្រវត្តិក៏អាចមានកំហុសឬភាពមិនត្រឹមត្រូវ។ ឯកសារដើមជាភាសាទីតាំងគួរត្រូវបានគេប្រើជាប្រភពច្បាស់លាស់។ សម្រាប់ព័ត៌មានសំខាន់ៗ សូមណែនាំឱ្យប្រើប្រាស់ការប្រែដោយមនុស្សជំនាញ។ យើងខ្ញុំមិនទទួលខុសត្រូវចំពោះការយល់ច្រឡំ ឬការបកស្រាយខុសបន្ទាប់ពីការប្រើប្រាស់ការបម្លែងនេះនោះទេ។