Có lẽ điểm đầu tiên để làm rõ là ID tin nhắn được xử lý trên cơ sở từng khách hàng và theo hướng. Điều đó có nghĩa là người môi giới sẽ tạo một ID tin nhắn cho mỗi tin nhắn gửi đi với QoS> 0 cho mỗi máy khách được kết nối và các ID tin nhắn này sẽ hoàn toàn độc lập với các ID tin nhắn khác được sử dụng cho cùng một tin nhắn được xuất bản cho các máy khách khác. Tương tự như vậy, mỗi khách hàng tạo ra các ID tin nhắn của riêng mình cho các tin nhắn mà nó gửi.
ID tin nhắn không phải là duy nhất, vì vậy khách hàng của bạn gửi 15 tin nhắn mỗi giờ với mức QoS 2 sẽ chỉ tràn vào một số điểm. Giới hạn thực sự là chỉ có thể có tối đa 65535 thông báo mỗi chiều "trong chuyến bay" cùng một lúc (tức là một phần thông qua việc bắt tay thông báo). Sau khi một tin nhắn với một ID đã cho đã được xử lý hoàn toàn thì có thể sử dụng lại ID tin nhắn đó. Một cách khác để xem xét nó là xem xét nó sẽ hoạt động như thế nào nếu khách hàng của bạn chỉ có một tin nhắn trong chuyến bay cùng một lúc, dù tỷ lệ tin nhắn được truyền đi hay bằng cách thiết kế theo cách bạn xử lý tin nhắn . Trong trường hợp này, bạn có thể giữ ID thư được đặt thành 1 cho mỗi thư đơn vì không bao giờ có cơ hội trùng lặp.
Nếu bạn muốn hỗ trợ có nhiều thư trong chuyến bay cùng một lúc, việc kiểm tra không có bản sao ID tin nhắn nào trước khi bạn gán một tin nhắn mới tương đối dễ dàng.
Vì ID tin nhắn là cho mỗi khách hàng, nếu bạn gửi một tin nhắn đến> 65535 khách hàng, sẽ không có khả năng xảy ra xung đột ID tin nhắn. Nếu bạn gửi> 65535 thư cho từng khách hàng cùng một lúc và luồng thư không hoàn tất thì sẽ có sự cố.
trả lời bình luận: "Tôi đã nhận thấy rằng tất cả các nhà môi giới MQTT có xu hướng cung cấp duy nhất cuối cùng nhắn QoS1/2":
Các nhà môi giới sẽ chỉ gửi tin nhắn cho khách hàng nó biết về. Nếu bạn kết nối lần đầu tiên không có cách nào để nhận tin nhắn từ quá khứ, với một ngoại lệ: các tin nhắn đã lưu lại. Nếu một tin nhắn được thiết lập để giữ lại thì đó là một giá trị "tốt được biết đến cuối cùng". Khi một khách hàng mới đăng ký nó sẽ được gửi tin nhắn được giữ lại ngay lập tức mà làm cho nó hữu ích cho những điều được cập nhật không thường xuyên. Tôi nghi ngờ đây là những gì bạn đang đề cập đến. Nếu bạn muốn một khách hàng có các thư được xếp hàng đợi khi nó không được kết nối thì bạn phải kết nối với tùy chọn "phiên sạch" được tắt để làm cho máy khách liên tục. Bạn cũng phải sử dụng QoS> 0 đăng ký và QoS> 0 ấn phẩm. Khi khách hàng của bạn kết nối lại (với phiên làm sạch vẫn được đặt thành vô hiệu hóa), các thư được xếp hàng đợi sẽ được gửi. Bạn thường có thể cấu hình số lượng tin nhắn để xếp hàng theo cách này trong môi giới, nơi bất kỳ tin nhắn nào khác sẽ bị loại bỏ. Một điểm quan trọng là việc xếp hàng các tin nhắn cho một máy khách mà trước đây không được kết nối không được thiết kế hỗ trợ.
Tôi hiểu điểm này, cảm ơn bạn đã trả lời bằng cách này. Tôi đã nhận thấy rằng mọi nhà môi giới MQTT chỉ có xu hướng phân phối thông điệp QoS1/2 cuối cùng. Nếu tôi muốn cung cấp thêm thì sao? Có gì hơn 65535? Tôi hiểu rằng điều này là rất khó nhưng có thể. Giải pháp bạn đề xuất phù hợp với số lượng người nhận đã biết. Tình huống mà tôi đang xử lý là tôi không biết có bao nhiêu người nhận và họ vẫn ở trong nhà máy. Về cơ bản, họ có thể ở đó nhưng không bao giờ đến. Và có thể có hàng nghìn người trong số họ. – radekg
Một điểm mà tôi không nói rõ ràng là ID tin nhắn là cho mỗi khách hàng và mỗi hướng. Tôi đã cập nhật câu trả lời để bao gồm điều đó. – ralight
Tôi cũng đã trả lời điểm khác của bạn. Nếu điều đó không rõ ràng, hãy để lại một bình luận khác. – ralight