Thiết kế một giao thức mạng cho dữ liệu thời gian thực/thiết bị di động

Question

Tôi đang phải đối mặt với một tình thế khó xử sau:

Thiết kế một giao thức mạng mới sẽ được sử dụng giữa các máy chủ (phần mềm Java) và máy tính để bàn và các khách hàng di động. Các khách hàng di động bao gồm J2ME, Android và có thể trong tương lai thậm chí iPhone.

Luồng dữ liệu là luồng thời gian thực, không đổi với các phần không thường xuyên hơn. Khách hàng hiển thị dạng sóng của dữ liệu này và cũng là dữ liệu không cần cập nhật ngay lập tức. Các khách hàng cũng nên được xác thực.

Tôi muốn tránh việc tạo triển khai giao thức TCP hoàn toàn tùy chỉnh từ đầu nếu có thể.

Những ngày này mọi người thường đề xuất làm mọi thứ theo phong cách REST mà tôi cũng thực sự thích. Trong trường hợp này tôi là một chút do dự mặc dù: làm thế nào bạn sẽ thực hiện một dòng dữ liệu liên tục trên đầu trang của REST? Một phản ứng HTTP chunked?

Tôi cũng đang xem xét các giao thức không rõ ràng (các giao thức hiện tại mà tôi đang thay thế là các giao thức nhị phân). Những giao thức hiện tại có vấn đề khá nghiêm trọng của họ nên chúng thực sự cần được thay thế.

Bộ đệm giao thức của Google trông giống như một ứng cử viên khá mạnh mẽ để xử lý các chi tiết cấp thấp, nhưng tôi không chắc liệu nó có thể được sử dụng từ Android hay không. Và tôi khá chắc chắn rằng việc thực hiện iPhone sẽ có vấn đề với nó là tốt.

Ngoài ra còn có BEEP, nhưng tôi nghĩ rằng nó khá nhiều người chết và tôi tự hỏi là nó đã từng được sử dụng rộng rãi chưa.

Bất kỳ ý tưởng nào?

Answer 1

Bạn có thể muốn xem RTP (Real-time Transport Protocol), có thể không trực tiếp hữu ích (và/hoặc có thể quá mức cần thiết), nhưng thiết kế của nó sẽ cung cấp cho bạn một số ý tưởng hay để làm việc. Và bạn cũng có thể sử dụng nó.

Answer 2

Tôi nghĩ rằng trước khi đi vào thiết kế giao thức bạn nên chăm sóc các vấn đề sau thực sự cẩn thận:

• Hầu như tất cả các giao thức ngoại trừ HTTP được lọc bởi tường lửa những ngày này. Thậm chí nhiều loại nội dung và cổng (trừ 80) có thể được lọc bởi các nhà cung cấp dịch vụ, đặc biệt là trong các dịch vụ dữ liệu di động. Vì vậy, hãy chắc chắn rằng bạn không có vấn đề tường lửa trong mạng mục tiêu của bạn trước khi chọn sử dụng hoặc thiết kế một giao thức.
• Kích thước và tốc độ quan trọng. Hãy thử sử dụng các giao thức hiệu quả cả về kích thước tin nhắn vận chuyển và mã hóa/giải mã (serialize/deserialize) tốc độ. Google Protocol Buffers cung cấp giải pháp đáng tin cậy cho vấn đề này.
• Kết nối luôn ngắt kết nối. Bạn không bao giờ có thể dựa vào kết nối để duy trì mở lâu vì thời gian chờ của NAT (15 phút theo mặc định), thời gian chờ giao thức (30 phút đối với TCP) và nhiều sự cố mạng hiện có. Vì vậy, không thích một giao thức trên khác chỉ vì nó giữ kết nối mở (nó có thể cố gắng, nhưng không bao giờ thành công). Gửi heartbeats là một thử tốt cho vấn đề thời gian chờ nhưng ngắt kết nối mạng vẫn không thể tránh khỏi.
• Vấn đề về thông lượng. Bằng thông lượng, ý tôi là số lượng thư được xử lý trong một khoảng thời gian (ví dụ: 1 giây). Sử dụng các giao thức không đồng bộ ngắt kết nối một máy khách sau khi nhận được thông báo của nó, thực sự giúp tăng thông lượng.Mặc dù không dựa vào kết nối với máy khách từ máy chủ để đẩy kết quả vì nhiều máy khách nằm phía sau NAT và tường lửa tránh kết nối trực tiếp từ bên ngoài. Cố gắng giữ kết nối mở hoặc thăm dò ý kiến ​​máy chủ cho kết quả. Tránh trạng thái trong một cuộc hội thoại cũng là phương pháp khác giúp mở rộng thông lượng ứng dụng khi số lượng khách hàng tăng lên.
• Không có thời gian thực trong các mạng WAN hiện có. Không tin tưởng những người nói rằng họ đã thực hiện một giao thức thời gian thực dựa trên các giao thức mạng diện rộng hiện có. Bạn không bao giờ có thể triển khai giao thức thời gian thực trên các giao thức thời gian thực. Bạn có thể làm hết sức mình và cầu nguyện cho mạng chạy nhanh. Điều đó có nghĩa là: Đừng dừng lại, làm hết sức mình.
• IO không chặn. NIO (Không chặn IO) là xu hướng hiện nay, được sử dụng hiệu quả trong lập trình mạng. Nó cho phép số lượng lớn các kết nối với việc sử dụng bộ nhớ ít hơn và số lượng hạn chế các luồng. Java 5 có hỗ trợ riêng cho NIO vốn rất nguyên thủy. Nhiều khung công tác, chẳng hạn như Apache MINA và Netty, đã được triển khai dựa trên Java NIO để làm cho chương trình không chặn dễ dàng hơn và mạnh mẽ hơn. Tôi đề nghị họ.

Answer 3

Bạn có thể xem Kryo và/hoặc KryoNet, là NIO và dựa trên Java và hoạt động trên máy tính để bàn và Android. Bạn sẽ phải viết bên iPhone mặc dù, đó sẽ là khá khó khăn. Kryo đánh bại Bộ đệm giao thức của Google theo kích thước được tuần tự hóa (benchmarks here) và dễ sử dụng (không cần phải viết lược đồ kiểu .proto, với Kryo các định nghĩa lớp Java là lược đồ).

Về NIO, bạn có thể xem NPTL. Cái cũ trở nên mới.

Answer 4

Đây không phải là giải pháp thanh lịch, nhưng bạn có thể thực hiện điều này qua http thẳng, bằng cách không đặt trường độ dài nội dung trên phản hồi http và không bao giờ đóng luồng đầu ra. Chỉ cần tiếp tục gửi dữ liệu.

Bạn cũng có thể đặt độ dài nội dung rất lớn và gửi dữ liệu trở lại từ máy chủ trong thời gian thực cho đến khi máy chủ gửi số tiền đó, sau đó khách hàng có thể chọn tạo yêu cầu mới.

Rất tiếc, tôi không thể tìm thấy bất kỳ liên kết hữu ích nào cho những ý tưởng này, nhưng tôi tin tưởng bạn có được ý tưởng.

Điểm cộng thực sự của những ý tưởng này là chúng vượt quá http, được phát hành bởi sự cố tường lửa và bạn có thể triển khai ứng dụng của mình dưới dạng webapp với servlet.

Chỉ 2 xu của tôi;)