Bộ đệm giao thức của Google so với ASN.1

Question

Sự khác biệt đáng chú ý nhất giữa Bộ đệm giao thức của Google và ASN.1 (với mã hóa PER) là gì? Đối với dự án của tôi, vấn đề quan trọng nhất là kích thước của dữ liệu tuần tự hóa. Có ai thực hiện bất kỳ so sánh kích thước dữ liệu giữa hai?

Answer 1

Đã lâu rồi kể từ khi tôi thực hiện bất kỳ tác phẩm ASN.1 nào, nhưng kích thước rất có thể phụ thuộc vào chi tiết về loại và dữ liệu thực tế của bạn.

Tôi sẽ mạnh khuyên bạn nên tạo mẫu thử cả hai và đưa một số dữ liệu thực vào để so sánh. Nếu bộ đệm giao thức của bạn chứa các kiểu nguyên thủy lặp đi lặp lại, bạn nên xem nguồn mới nhất trong Subversion cho Protocol Buffers - chúng có thể được biểu diễn theo định dạng "đóng gói" hiện nay có hiệu quả về mặt không gian hơn nhiều. (Cổng C# của tôi có chỉ cần bắt kịp với tính năng này, một số thời gian trong tuần trước.)

Answer 2

Nếu bạn sử dụng ASN.1 với PER chưa được ký hiệu và xác định loại dữ liệu của bạn bằng cách sử dụng các ràng buộc thích hợp (ví dụ: chỉ định thấp hơn/trên giới hạn cho số nguyên, giới hạn trên cho độ dài của danh sách, v.v.), mã hóa của bạn sẽ rất nhỏ gọn. Sẽ không có bit bị lãng phí cho những thứ như căn chỉnh hoặc đệm giữa các trường và mỗi trường sẽ được mã hóa trong số bit tối thiểu cần thiết để giữ phạm vi giá trị được cho phép của nó. Ví dụ, một trường kiểu INTEGER (1..8) sẽ được mã hóa thành 3 bit (1 = '000', 2 = '001', ..., 8 = '111'); và SỰ LỰA CHỌN với bốn lựa chọn thay thế sẽ chiếm 2 bit (chỉ ra lựa chọn thay thế) cộng với các bit bị chiếm bởi lựa chọn thay thế. ASN.1 có nhiều tính năng thú vị khác đã được sử dụng thành công trong nhiều tiêu chuẩn được xuất bản. Một ví dụ là dấu mở rộng ("..."), khi được áp dụng cho SEQUENCE, CHOICE, ENUMERATED và các loại khác, cho phép tương thích ngược và tiến giữa các điểm cuối thực hiện các phiên bản khác nhau của đặc tả.

Answer 3

Khi kích thước của gói tin/mã hóa là rất quan trọng bạn cũng nên lưu ý một thực tế rằng protobuf không có khả năng để đóng gói repeated lĩnh vực mà không phải là của một primitive numeric type, read this để biết thêm thông tin.

Đây là sự cố, ví dụ: nếu bạn có tin nhắn kiểu đó: (comment xác định phạm vi thực tế của giá trị)

message P{ 
    required sint32 x = 1; // -0x1ffff to 0x20000 
    required sint32 y = 2; // -0x1ffff to 0x20000 
    required sint32 z = 3; // -0x319c to 0x3200 
} 
message Array{ 
    repeated P ps = 1; 
    optional uint32 somemoredata = 2; 
} 

Trong trường hợp bạn có một chiều dài mảng, ví dụ, 32 hơn bạn sẽ cho kết quả trong một kích thước thư đóng gói khoảng 250-450 byte với protobuf, tùy thuộc vào giá trị thực sự của mảng. Điều này thậm chí có thể tăng lên hơn 1000 byte trong trường hợp bạn sử dụng phạm vi 32bit đầy đủ hoặc trong trường hợp bạn sử dụng int32 thay vì sint32 và có giá trị âm.

Dữ liệu thô blob (giả định rằng z có thể được định nghĩa là giá trị int16) sẽ chỉ tiêu thụ 320 byte và do đó ASN.1 nhắn là luôn nhỏ hơn 320 byte kể từ khi giá trị tối đa là thực sự không 32bit nhưng 19 bit (x, y) và 15 bit (z).

Kích thước nhắn protobuf có thể được tối ưu hóa với định nghĩa thông điệp này:

message Ps{ 
    repeated sint32 xs = 1 [packed=true]; 
    repeated sint32 ys = 2 [packed=true]; 
    repeated sint32 zs = 3 [packed=true]; 
} 
message Array{ 
    required Ps ps = 1; 
    optional uint32 somemoredata = 2; 
} 

mà kết quả trong thông điệp kích thước giữa khoảng 100 byte (tất cả các giá trị là số không), 300 byte (giá trị ở cự ly tối đa), và 500 byte (tất cả các giá trị là các giá trị 32 bit cao).