XMPP: thêm tính hai chiều vào pubsub?

Question

Tôi không chắc chắn nếu pubsub hoặc multiuserchat là con đường để đi?

Điều tôi nghĩ tôi cần là pubsub, nhưng với khả năng bổ sung để người đăng ký cũng có thể truyền phát tin nhắn đến nguồn cấp dữ liệu. Dòng thông tin hai chiều, nếu bạn muốn.

Trường hợp sử dụng sao cho thuê bao sẽ được đăng ký trung bình 1000 nguồn cấp dữ liệu khác nhau, nhưng mỗi nguồn cấp dữ liệu riêng lẻ chỉ phát thông tin trung bình một lần mỗi tuần. Vì vậy, rất nhiều nguồn cấp dữ liệu, nhưng hoạt động thấp trong mỗi một. Tuy nhiên, b/c có 1000 đăng ký hoạt động khác nhau, người đăng ký có thể vẫn được thông báo 100 tin nhắn mỗi ngày và họ có thể "trả lời" nội dung bài đăng cho bất kỳ nguồn cấp dữ liệu nào trong số đó.

Có vẻ như những gì tôi cần là kết hợp pubsub/multiuserchat. Nhưng điều đó không tồn tại, hay không? Bất kỳ ý tưởng hoặc con trỏ?

Cảm ơn một nhóm!

Answer 1

Nếu người đăng ký đang xuất bản dữ liệu thì họ không chỉ là người đăng ký, họ là nhà xuất bản. Và không có lý do gì mà cùng một thực thể không thể là nhà xuất bản và người đăng ký cùng một lúc.

Đối với câu hỏi tổng quát hơn của bạn về pubsub so với MUC, đó là câu hỏi mà tôi thấy có rất nhiều hiện nay.

Rõ ràng ngay từ cái nhìn đầu tiên MUC và pubsub rất giống nhau, cả hai đều về phát sóng cho một nhóm. Nhiều ứng dụng có thể dễ dàng sử dụng một hoặc ứng dụng khác mà không gặp sự cố nào.

Để giúp quyết định loại nào phù hợp nhất với ứng dụng của bạn, hãy xem xét một số khác biệt giữa hai giao thức.

MUC:

1. là hoàn toàn tốt cho chatroom tiêu chuẩn của người dùng trực tuyến giao tiếp với nhau. Nếu đây là những gì bạn đang làm, hãy sử dụng nó.
2. Bao gồm sự hiện diện, tức là thông báo cho những người cư ngụ khác về việc tham gia, rời khỏi và thay đổi trạng thái.
3. Cho phép liên lạc riêng ẩn danh giữa những người cư ngụ.
4. Làm việc ra khỏi hộp với thực tế bất kỳ ứng dụng XMPP chuẩn nào (đối với các tin nhắn trò chuyện chuẩn).
5. Tự động rời khỏi phòng khi người dùng chuyển sang ngoại tuyến hoặc ngắt kết nối.
6. Tin nhắn có tải trọng tùy chỉnh được hỗ trợ, nghĩa là bạn bị giới hạn định tuyến tin nhắn trò chuyện chuẩn.

PubSub:

1. Một hoặc một vài nhà xuất bản truyền tới nhiều thuê bao read-only là lãnh thổ pubsub lõi. Ngược lại với MUC, người đăng ký không xuất bản và không nhận được thông tin về những người đăng ký khác.
2. Triển khai máy chủ có xu hướng kiểm soát truy cập linh hoạt hơn nhiều đối với pubsub.
3. Chỉ tải trọng tùy chỉnh, không có tin nhắn trò chuyện chuẩn.
4. Tùy chọn có toàn bộ mục kiên trì.
5. Nút có thể được quản lý dưới dạng danh sách các mục (ví dụ: thêm/xóa bằng thông báo) thay vì chỉ phát sóng đơn giản.
6. Đăng ký có thể tồn tại thông qua việc ngoại tuyến.

Các điểm trên chỉ là hướng dẫn. Rất nhiều thông thường có thể đạt được thông qua cấu hình máy chủ. Ví dụ, đặc tả MUC cho phép phòng giữ lại các chương trình phát sóng hiện diện cho các lớp người cư ngụ nhất định dựa trên cấu hình. Việc nắm bắt ở đây là trong việc triển khai ... vì đây là cách sử dụng MUC không phổ biến, bạn sẽ thấy nó có thể không được hỗ trợ trong nhiều triển khai MUC. Vấn đề là MUC được thiết kế để trò chuyện và không phải là pubsub chung, bạn sẽ tìm thấy tất cả các triển khai và công cụ xung quanh MUC để tập trung vào cách sử dụng đó.

Answer 2

Không chắc chắn vấn đề là gì. Người đăng ký cũng chỉ cần trở thành nhà xuất bản. Không có gì ngăn họ xuất bản cũng như đăng ký (trừ khi các nút được cấu hình để không cho phép nó).

Đây có vẻ là trường hợp pubsub rất điển hình.