2012-07-26 21 views
11

Khi sử dụng Server-Sent Events, khách hàng có nên thiết lập nhiều kết nối để nhận các sự kiện khác nhau mà họ quan tâm hoặc nên có một kết nối duy nhất và khách hàng cho biết những gì họ quan tâm thông qua một kênh riêng biệt? IMO sau này có vẻ thích hợp hơn mặc dù một số nó có thể làm cho mã khách hàng phức tạp hơn. Spec hỗ trợ các sự kiện được đặt tên (các sự kiện liên quan đến một chủ đề cụ thể), mà cho tôi gợi ý rằng một kết nối Sự kiện Máy chủ-Sự kiện sẽ được sử dụng làm kênh đơn cho tất cả các sự kiện.Chỉ nên có một đối tượng EventSource cho mỗi ứng dụng?

Các mã sau minh họa kịch bản đầu tiên, nơi một nhiều kết nối máy chủ sự kiện-Sent được khởi xướng:

var EventSource eventSource1 = new EventSource("events/topic1"); 
eventSource1.addEventListener('topic1', topic1Listener, false); 

var EventSource eventSource2 = new EventSource("events/topic2"); 
eventSource2.addEventListener('topic2', topic2Listener, false); 

eventSource1 sẽ nhận được "topic1" các sự kiện và eventSource2 sẽ nhận được "topic2" sự kiện. Trong khi điều này là khá thẳng về phía trước nó cũng khá hiệu quả với một treo GET xảy ra cho mỗi chủ đề bạn quan tâm đến

Cách khác là một cái gì đó như sau:.

var EventSource eventSource3 = new EventSource("/events?id=1234") 
eventSource3.addEventListener('topic3', topic3Listener, false); 
eventSource3.addEventListener('topic4', topic4Listener, false); 

var subscription = new XMLHttpRequest(); 
subscription.open("PUT", "/events/topic3?id=1234", true); 
subscription.send(); 

Trong ví dụ này một EventSource đơn sẽ tồn tại và quan tâm đến một sự kiện cụ thể sẽ được chỉ định bởi một yêu cầu riêng biệt với kết nối Sự kiện do máy chủ gửi và đăng ký được tương quan bởi tham số id. topic3Listener sẽ nhận được các sự kiện "topic3" và topic4Listener sẽ không nhận được. Trong khi yêu cầu nhiều mã hơn, lợi ích là chỉ có một kết nối được thực hiện, nhưng các sự kiện vẫn có thể được xác định và xử lý khác nhau.

Có một số ví dụ trên web hiển thị việc sử dụng các sự kiện được đặt tên, nhưng có vẻ như tên sự kiện (hoặc chủ đề) được biết trước vì vậy không cần khách hàng đăng ký sở thích với máy chủ (example)). Trong khi tôi chưa thấy một ví dụ hiển thị nhiều đối tượng EventSource, tôi cũng chưa thấy một ví dụ cho thấy một khách hàng sử dụng một yêu cầu riêng biệt để đăng ký sở thích trong một chủ đề cụ thể, như tôi đang làm ở trên. Việc giải thích thông số của tôi khiến tôi tin rằng chỉ ra một sở thích trong một chủ đề (hoặc tên sự kiện) nào đó hoàn toàn phụ thuộc vào nhà phát triển và nó có thể được thực hiện tĩnh với khách hàng biết tên của các sự kiện mà nó sẽ nhận hoặc tự động với máy khách thông báo cho máy chủ rằng nó quan tâm đến việc nhận các sự kiện cụ thể.

Tôi rất muốn nghe suy nghĩ của người khác về chủ đề này. NB: Tôi thường là nhà phát triển Java vì vậy hãy tha thứ cho mã JS tầm thường của tôi .. :)

+0

bạn có thể không sử dụng ở tất cả các tên sự kiện trong sự kiện của bạn-stream, thay vào đó bạn có thể nghe cho sự kiện "thông báo" và trong event.data bạn có thể mã hóa topicId của bạn và thông tin bổ sung – 4esn0k

+0

Vâng chắc chắn, nhưng điều đó sẽ có nghĩa là tôi cần mã hóa dữ liệu đó trong tải trọng không thực sự có ý nghĩa khi nhận dạng tin nhắn đã là một phần của khung dữ liệu của thông số kỹ thuật. –

+1

+1! câu hỏi rất hay. Bạn đã làm gì? Tôi cũng nghĩ đến việc đi với phương pháp thứ hai. Sẽ đánh giá cao nếu bạn chia sẻ cho dù bạn gặp phải bất kỳ vấn đề với nó. – brainOverflow

Trả lời

3

Tôi rất muốn giới thiệu, IMHO, bạn có một đối tượng EventSource cho mỗi dịch vụ cung cấp SSE, và sau đó phát ra các thông báo bằng các loại khác nhau .

Cuối cùng, tuy nhiên, tùy thuộc vào mức độ tương tự của các loại thông báo. Ví dụ: nếu bạn có 5 loại thông báo khác nhau liên quan đến người dùng, hãy có người dùng EventSource và phân biệt với các loại sự kiện.

Nếu bạn có một loại sự kiện về người dùng và loại sự kiện khác về bánh mì, tôi muốn giữ chúng trong các dịch vụ khác nhau và do đó EventSource s.

Bạn nên nghĩ đến việc chia nhỏ EventSources giống như cách bạn sẽ làm một dịch vụ an toàn. Nếu bạn không nhận được hai thứ từ cùng một dịch vụ với AJAX, có thể bạn không nên lấy chúng từ cùng một EventSource.

+0

Quy mô đó có hiệu quả không? – nilskp

0

Để đáp ứng với diễn giải tiêu chuẩn trình duyệt mơ hồ và dễ hiểu *, nhà cung cấp trình duyệt đã thực hiện không nhất quán các hạn chế đối với số lượng kết nối liên tục được phép cho một tên miền/cổng.Do mỗi bộ thu sự kiện vào một bối cảnh không đồng bộ giả định một kết nối liên tục duy nhất cho đến khi người nhận đó mở, điều quan trọng là số lượng trình lắng nghe EventSource bị hạn chế nghiêm ngặt để tránh vượt quá giới hạn khác nhau của nhà cung cấp. Trong thực tế, điều này giới hạn bạn khoảng 6 cặp ngữ cảnh EventSource/async cho mỗi ứng dụng. Sự xuống cấp là duyên dáng (ví dụ như các yêu cầu kết nối EventSource bổ sung sẽ chỉ đợi cho đến khi có chỗ trống), nhưng lưu ý rằng phải có sẵn các kết nối để truy xuất tài nguyên trang, trả lời XHR, v.v.

* W3C đã ban hành các tiêu chuẩn liên quan đến các kết nối liên tục có chứa ngôn ngữ “… NÊN giới hạn số lượng kết nối đồng thời…” Ngôn ngữ này có nghĩa là tiêu chuẩn không bắt buộc để tuân thủ của nhà cung cấp có thể thay đổi. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4

Các vấn đề liên quan