3 ms·
Interesting idea. Are you planning on opening up other zeromq protocols like pub/sub? The web server could validate the subscription before establishing the co
by jrussbowman 15y ago
Interesting idea. Are you planning on opening up other zeromq protocols like pub/sub?
The web server could validate the subscription before establishing the connection. That would be a little easier for setting up control over who has access to what resources. I suppose you could do this with REQ/REP but PUB/SUB would simplify the server side implementation.
For my current project I'm using PUSH/PULL with filtering at the server because it was fewer connections to deal with between the web server and zeromq router. PUB/SUB directly between the router and end user client could potentially cut down on bandwidth for a large implementation.
- hogu 15y agoI have already opened up SUB sockets, so that on the JS side can connect as a SUB socket to a PUB - do you mean allowing the JS side to connect as a PUB? In its current state, people who connect as a SUB socket have the option of passing in a msgfilter in their authentication data, the rationale being that you might only want to authenticate certain users to listen to certain types of messages.
- hogu 15y agoI also wanted to mention, that on the REQ REP side, in the bridge I actually implement the REQ as an XREQ socket, that way I only need one XREQ socket for all js side REQ sockets. I simply tag the message with the identity of the js REQ socket. I had thought it would be nice originally to create a one to one mapping between javscript side REQ sockets and server side REQ sockets, however creating one zmq socket per js client may present scaling problems, running out of file descriptors, etc..