Netty + ProtoBuffer: Một vài thông báo liên lạc cho một kết nối

Question

Khi đọc hướng dẫn Netty, tôi đã tìm thấy một description đơn giản về cách tích hợp Netty và Google Protocol Buffers. Tôi đã bắt đầu điều tra ví dụ của nó (vì không có thêm thông tin trong tài liệu) và viết một ứng dụng đơn giản như ứng dụng thời gian địa phương ví dụ. Nhưng ví dụ này là sử dụng khởi tạo tĩnh trong PipeFactory Class, ví dụ:

import org.jboss.netty.channel.ChannelPipeline; 
import org.jboss.netty.channel.ChannelPipelineFactory; 
import org.jboss.netty.handler.codec.protobuf.ProtobufDecoder; 
import org.jboss.netty.handler.codec.protobuf.ProtobufEncoder; 
import org.jboss.netty.handler.codec.protobuf.ProtobufVarint32FrameDecoder; 
import org.jboss.netty.handler.codec.protobuf.ProtobufVarint32LengthFieldPrepender; 

import static org.jboss.netty.channel.Channels.pipeline; 

/** 
* @author sergiizagriichuk 
*/ 
class ProtoCommunicationClientPipeFactory implements ChannelPipelineFactory { 

    public ChannelPipeline getPipeline() throws Exception { 
     ChannelPipeline p = pipeline(); 
     p.addLast("frameDecoder", new ProtobufVarint32FrameDecoder()); 
     p.addLast("protobufDecoder", new ProtobufDecoder(Communication.DataMessage.getDefaultInstance())); 

     p.addLast("frameEncoder", new ProtobufVarint32LengthFieldPrepender()); 
     p.addLast("protobufEncoder", new ProtobufEncoder()); 

     p.addLast("handler", new ProtoCommunicationClientHandler()); 
     return p; 
    } 

} 

(Xin hãy xem tại dòng p.addLast("protobufDecoder", new ProtobufDecoder(Communication.DataMessage.getDefaultInstance()));) và chỉ là một nhà máy có thể được tạo ra (như tôi hiểu) cho ClientBootstrap lớp, ý tôi là bootstrap.setPipelineFactory() phương pháp . Vì vậy, trong tình huống này, tôi có thể sử dụng ONE nhắn gửi đến máy chủ và ONE nhắn nhận được từ máy chủ và nó có hại cho tôi, và tôi nghĩ rằng không chỉ cho tôi :(Làm thế nào tôi có thể sử dụng thông điệp khác nhau đến và đi từ chỉ một kết nối? có lẽ tôi có thể tạo ra một vài protobufDecoder như

p.addLast("protobufDecoder", new ProtobufDecoder(Communication.DataMessage.getDefaultInstance())); 
p.addLast("protobufDecoder", new ProtobufDecoder(Communication.TestMessage.getDefaultInstance())); 
p.addLast("protobufDecoder", new ProtobufDecoder(Communication.SrcMessage.getDefaultInstance())); 

hoặc kỹ thuật khác này? Thanks a lot.

Answer 1

Tôi đã tìm thấy chủ đề của tác giả của netty trong google groups và hiểu rằng tôi phải thay đổi kiến ​​trúc hoặc viết bộ giải mã của riêng mình như tôi đã viết ở trên, Vì vậy, Bắt đầu nghĩ cách nào sẽ dễ dàng và tốt hơn.

Answer 2

về mặt lý thuyết này có thể được thực hiện bằng cách thay đổi các đường ống dẫn cho mỗi tin nhắn gửi đến cho phù hợp tin nhắn đến. Hãy xem port unification ví dụ trong Netty.

trình tự sẽ là:
1) Trong bộ giải mã khung này hay cách khác "DecoderMappingDecoder" bạn đánh dấu vào loại thông điệp của tin nhắn gửi đến
2) Sửa đổi các đường ống dẫn động như thể hiện trong ví dụ

Nhưng tại sao không sử dụng kết nối khác nhau và làm theo trình tự này:
1) Thêm bộ giải mã khác trong đường ống dựa trên tin nhắn gửi đến chỉ một lần.
2) Thêm cùng trường hợp xử lý ngược dòng kênh làm trình xử lý cuối cùng trong đường ống, theo cách này tất cả các thư được định tuyến đến cùng một cá thể, gần giống như có một kết nối.

Answer 3

Vấn đề không phải là khá hạn chế hoặc encoder/decoder giới hạn Netty. Vấn đề là bộ đệm giao thức của Google đang cung cấp chỉ là một cách để tuần tự hóa/deserialize các đối tượng, nhưng không cung cấp một giao thức. Họ có một số loại thực hiện RPC như một phần của phân phối chuẩn, nhưng nếu bạn sẽ cố gắng thực hiện giao thức RPC của họ sau đó bạn sẽ kết thúc với 3 lớp về mình. Những gì tôi đã làm trong một trong những dự án, là để xác định một thông điệp rằng về cơ bản là một liên minh các thông điệp. Thư này chứa một trường là Loại và trường khác là thông điệp thực tế. Bạn sẽ vẫn kết thúc với 2 lớp không giới hạn, nhưng không phải 3. Theo cách này, ví dụ từ Netty sẽ làm việc cho bạn, nhưng như đã đề cập trong bài trước, bạn phải đặt thêm logic vào trình xử lý logic nghiệp vụ.

Answer 4

Nếu bạn đang đi để viết các codecs riêng của mình dù sao, bạn có thể muốn xem xét việc thực hiện các giao diện Externalizable cho các đối tượng dữ liệu tùy chỉnh.

• Có thể lập trình lại là nỗ lực thấp nhưng hiệu suất kém nhất (sắp xếp mọi thứ).
• Protobuf là một trade-off tốt giữa nỗ lực và hiệu suất (yêu cầu .proto bảo trì)
• Externalizable là nỗ lực cao, nhưng hiệu suất tốt nhất (codec tùy chỉnh tối thiểu)

Nếu bạn đã biết dự án của bạn sẽ có để quy mô như một con dê núi, bạn có thể phải đi con đường khó khăn. Protobuf không phải là viên đạn bạc.

Answer 5

vấn đề là không có cách nào để phân biệt hai thông điệp protobuf khác nhau với nhau ở định dạng nhị phân. Nhưng có một cách để giải quyết nó trong tệp protobuf:

message AnyMessage { 
    message DataMessage { [...] } 
    optional DataMessage dataMessage = 1; 
    message TestMessage { [...] } 
    optional TestMessage testMessage = 2; 
    message SrcMessage { [...] } 
    optional SrcMessage srcMessage = 3; 
} 

trường tùy chọn không được đặt không tạo ra chi phí. Ngoài ra, bạn có thể thêm một Enum, nhưng nó chỉ là một tiền thưởng.

Answer 6

Bạn có thể sử dụng đường hầm thông báo để gửi các loại tin nhắn khác nhau dưới dạng tải trọng trong một tin nhắn đơn. Hy vọng rằng sẽ giúp

Answer 7

Sau khi nghiên cứu và chịu đau khổ dài ... Tôi nghĩ ra cách sử dụng thành phần của thư thành một thông báo trình bao bọc. Bên trong thông báo đó, tôi sử dụng phím oneof để giới hạn số lượng đối tượng được phép thành chỉ. Hãy kiểm tra ví dụ:

message OneMessage { 
    MessageType messageType = 1; 

    oneof messageBody { 
     Event event = 2; 
     Request request = 3; 
     Response response = 4; 
    } 

    string messageCode = 5; //unique message code 
    int64 timestamp = 6; //server time 
}