v19.3.0 update-related queston

[ramblehead]

First of all, I would like to say thank you for implementing and open-sourcing uWebSockets! - it is one of the most elegant projects I have seen (my only wish is that it could work on bare hardware, especially when QUIC is implemented :)

To evaluate uWebSockets I implemented a small rpc server badware in node with an aim to port it to c++ when all works. The client badware is in browser.

The rpc server uses publish() to multicast to all clients - including self. Everything worked as expected until v19.3.0 that stopped publishing to self, which broke my badware logic. Would there be some flag to re-enable "publish to self" or the right way is to use send() right after publish()?

PS https://xkcd.com/1172/

[hst-m]

v19.0 added app.publish and made ws.publish not publish to self. v19.3 fixed bug where ws.publish incorrectly published to self #1269 (comment) Sounds like you were using ws.publish but in v19 you need to use app.publish, see example: https://github.com/uNetworking/uWebSockets/blob/master/examples/Broadcast.cpp#L73

[ghost]

Hahaha that strip..

Yes app.publish does what you want

[ramblehead]

@hst-m and @alexhultman, thank you for answering - app.publish() works with "publish to self"!

Broadcast.cpp is using app variable before app.run(). Looks like the node interface does not provide app.run(), so attaching app to ws object in ws.open handler.

From Broadcast.cpp, seems that it worth diving into uSockets when codding uWS in C++...
Is there some equivalent of emacs run-with-idle-timer function? - i.e. to run a callback when connection is idle for some secs - such as, to run ws.service.ws.ping().

[hst-m]

so attaching app to ws object in ws.open handler

For node.js you would assign app variable at top, then use it anywhere

app=require('uWebSockets.js').App().ws('/',{
   open:ws=>app.publish(topic,message)
})

[ramblehead]

@hst-m thank you for the snippet! - that is similar to what I used: open handler has access to ws as a parameter and to app as a module global. Attaching app to ws (back-referencing) allows other event handlers (such as message) to access app via ws parameter avoiding module globals. It could be a useful pattern when delegating the actual handler logic to other modules that do not have access to the original global app variable.