docs(kitex): clarify distinction between Unary and Ping Pong modes in streaming documentation

Author: XinyiWang0204

content/en/docs/kitex/Tutorials/advanced-feature/generic-call/generic_streaming.md

@@ -42,10 +42,10 @@ service Echo {
 
 The four methods included in the example IDL correspond to four scenarios:
 
-1. Client streaming: the client sends multiple messages, the server returns one message, and then closes the stream.
-2. Server streaming: The client sends one message, the server returns multiple messages, and then closes the stream. It's suitable for LLM scenarios.
-3. Bidirectional streaming: The sending and receiving of client/server are independent, which can be organized in arbitrary order.
-4. Unary: non streaming.
+1. Client Streaming: the client sends multiple messages, the server returns one message, and then closes the stream.
+2. Server Streaming: The client sends one message, the server returns multiple messages, and then closes the stream. It's suitable for LLM scenarios.
+3. Bidirectional Streaming: The sending and receiving of client/server are independent, which can be organized in arbitrary order.
+4. Unary: In gRPC, this is a single call mode without using streams, similar to the Ping Pong mode in Thrift.
 
 First of all, please initialize the streaming client. Here is an example of streaming client initialization.
 
@@ -100,11 +100,11 @@ service TestService {
 
 The four methods included in the example IDL correspond to four scenarios:
 
-1. Client streaming: the client sends multiple messages, the server returns one message, and then closes the stream.
-2. Server streaming: The client sends one message, the server returns multiple messages, and then closes the stream. It's suitable for LLM scenarios.
-3. Bidirectional streaming: The sending and receiving of client/server are independent, which can be organized in arbitrary order.
-4. Unary (gRPC): Non-streaming. With `streaming.mode` annotation. Not recommended due to performance loss.
-5. Unary (KitexThrift): Non-streaming. Recommended.
+1. Client Streaming: the client sends multiple messages, the server returns one message, and then closes the stream.
+2. Server Streaming: The client sends one message, the server returns multiple messages, and then closes the stream. It's suitable for LLM scenarios.
+3. Bidirectional Streaming: The sending and receiving of client/server are independent, which can be organized in arbitrary order.
+4. Unary (gRPC): Non-streaming with `streaming.mode` annotation. Not recommended due to performance loss.
+5. Ping Pong mode (KitexThrift): Traditional Thrift request-response pattern without using streams. Better performance, recommended.
 
 Here is an example of streaming client initialization.
 

content/zh/docs/kitex/Tutorials/advanced-feature/generic-call/generic_streaming.md

@@ -44,7 +44,7 @@ service StreamingService {
 1. Client Streaming：客户端发送多条消息，服务端返回一条消息后关闭流。
 2. Server Streaming：客户端发送一条消息，服务端返回多条消息后关闭流，适合大模型等场景。
 3. Bidirectional Streaming：客户端和服务端可独立收发消息，顺序可自定义。
-4. Unary：单次调用（非流式）。
+4. Unary：gRPC 中的单次调用模式，不使用流机制，类似于 Thrift 中的 Ping Pong 模式。
 
 流式客户端初始化示例：
 
@@ -112,7 +112,7 @@ service TestService {
 2. 服务端流：客户端发送一条消息，服务端返回多条消息后关闭流，适合大模型等场景。
 3. 双向流：客户端和服务端可独立收发消息，顺序可自定义。
 4. 单次调用（gRPC）：带 `streaming.mode` 注解的非流式（不推荐，性能有损失）。
-5. 单次调用（KitexThrift）：非流式（推荐）。
+5. Ping Pong 模式（KitexThrift）：传统的 Thrift 一发一收模式，不使用流机制，性能更好，推荐使用。
 
 流式客户端初始化示例：