|
|
Post by francine on May 17, 2018 10:34:17 GMT
Hi all,
I need to implement a server-side eventing mechanism.
Is it possible to implement it with HTML5 web-socket ?
As far as I can understand, the mockup client example uses a "socket - accept()" mechanism, not a HTML5 websocket,
so is it mandatory to do exactly the same ?
I mean, all Redfish clients would have a "server-side socket accept" mechanism.
It is not clear for me in the specification (well, I am a beginner ;-)
So in other words, is it acceptable (compliant, conform...) to implement Eventing (publish-subscribe) only with web-socket principles ?
I apologize if ever the answer is obvious, I may miss something (and I am french ;-)
Best regards,
Francine
|
|
|
|
Post by mraineri on May 18, 2018 19:23:43 GMT
We actually recently added support for using SSE as a method of receiving events. Within section 8.5 of version 1.5.0 of the Redfish Specification ( www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.5.0.pdf), we allow for a client to perform a GET on a URI specified by a new property in the EventService called "ServerSentEventUri". All events generated by the service will be sent to the client on the open socket. So, with this mechanism, a client does not need to make a subscription, and wait for events to be published. However, our mockup server tool does not support this sort of functionality. The mockup server is a very simple service that just provides single JSON files when a client makes a GET request. |
|
|
|
Post by francine on May 30, 2018 6:48:56 GMT
Thanks a lot, mraineri, to take some of your time to answer me so clearly.
|
|
|
|
Post by francine on May 30, 2018 14:10:39 GMT
I finally implement an SSE mechanism for the eventing.
So, I have 2 more questions
1. Event Type : There is no "real" subscription, I mean the client does NOT send a subscription with needed Event Types. The only subscription contains the Event Destination, but no event types desired by the client. So when I send a message from one side, every suscribers receives every message, did I miss somehting ?
2. Should I implement a WebSocket (that dispatchs messages to all waiters) or an EventSource/emit from client side ?
Regards,
Francine
|
|
|
|
Post by mraineri on Jun 6, 2018 11:56:08 GMT
You're correct in that there is no real subscription. When a client connects to the SSE URI, all events tracked by the service will be reported to the client. In this model, the client performs the event filtering when it receives data on the SSE connection.
Unfortunately I do not know how to answer your second question; ultimately you should be doing what makes the most sense for your implementation. I imagine you'd probably have a single source where events are generated, and that would be the place to push data to all open SSE connections.
|
|
