I write a multithreaded application and would like to send and receive messages (RPC like) in parallel. Both client and server should be able to send requests.
Is this possible with nng? With only one connection, or do I need to set up two connections?
Is nng threadsafe in that regard?
Can you point me to an example?
Thanks in advance!
Related
is it technically possible to run multiple websocket servers that listen on the same port and dispatch using the subprotocol name ? E.g. a process that would handle "protocol1" and another that would handle "protocol2". My guess is that it is not, since TCP cannot conditionally accept a connection, so the only way would be some kind of socket ownership transfer.
Actually, it would be possible to achieve by using a Proxy as a load balancer, which isn't something I tried managing before... So I can't post a demo configuration file.
I know Apache will allow you to decide on a proxy path according to the request headers - this means you can check the sub protocol before forwarding the data... But this is mostly a conceptual solution I never tested.
This question is tagged WebSocket++, so I will answer from the context of that library.
Maybe, depending on exactly what you mean. WebSocket++ will let you build one program that can internally handle multiple subprotocols. WebSocket++ has a pre-acceptance hook called the validate handler. In the validate handler you are presented with a list of subprotocols the client has requested and may choose which one you want to accept (or none if your server doesn't support any).
This isn't the same as conditionally accepting the TCP connection itself, but does let you conditionally accept the WebSocket connection. Once accepted your app can inspect the selected subprotocol in the open handler and choose which logic to use to process the connection.
A WebSocket++ based program can juggle multiple connections on multiple subprotocols simultaneously. If you truly want multiple independent processes handling each then the best WebSocket++ will be able to do is act as a proxy for those connections.
My network has one server and possibly thousands of clients. In most cases, the server sends a command to one of the clients and the client immediately sends a response. But there are cases wherein the client initiates the communication to the server, that is the client sends a status update to the server but then does not need to wait for the server's reply.
I am quite new to zeromq, I would like to ask what kind of pattern suits this kind of communication?
I think The Asynchronous Client/Server Pattern is exactly what you need.
Maybe I missed this in the docs, but how do you use ZeroMQ for simple signaling between multiple nodes? Something like REQ to REQ, with no REPs.
Example: I sometimes want to tell all other nodes to invalidate cache pages or notify them that something happened.
Request-reply won't work because I don't want the requester to block waiting for an empty response. I want to allow multiple signals to build up at the server.
Publish-subscribe feels wrong because I'd have to subscribe to everything, and start two sockets, one for each direction of communication.
PAIRs don't support automatically reconnecting and have other limitations.
Is pub-sub the best way to go? Or am I better just to use a traditional socket, write to both ends, and handle disconnections/reconnecting?
What you want is a dealer socket in your client side and a dealer socket on your server side. If you want to be able to send message to a specific node from the server side, then you better use a router socket in the server.
How can a client both subscribe and listen to replies with zeromq?
That is, on the client side I'd like to run a loop which only receives messages and selectively sends requests, and on the server side I'd like to publish most of the time, but to sometimes receive requests as well.
It looks like I'll have to have two different sockets - one for each mode of communication. Is it possible to avoid that and on the server side receive "request notifications" from the socket on a zeromq callback thread while pushing messages to the socket in my own thread?
I am awfully new to ZeroMQ, so I'm not sure if what you want is considered best-practice or not. However, a solution using multiple sockets is pretty simple using zmq_poll.
The basic idea would be to have both client and server:
open a socket for pub/sub
open a socket for req/rep
multiplex sends and receives between the two sockets in a loop using zmq_poll in an infinite loop
process req/rep and pub/sub events within the loop as they occur
Using zmq_poll in this manner with multiple sockets is nice because it avoids threads altogether. The 0MQ guide has a good example here. Note that in that example, they use a timeout of -1 in zmq_poll, which causes it to block until at least one event occurs on any of the multiplexed sockets, but it's pretty common to use a timeout of x milliseconds or something if your loop needs to do some other work as well.
You can use 2 threads to handle the different sockets. The challenge is that if you need to share data between threads, you need to synchronize it in a safe way.
The alternative is to use the ZeroMQ Poller to select the sockets that have new data on them. The process would then use a single loop in the way bjlaub explained.
This could be accomplished using a variation/subset of the Majordomo Protocol. Here's the idea:
Your server will be a router socket, and your clients will be dealer sockets. Upon connecting to the server, the client needs to send some kind of subscription or "hello" message (of your design). The server receives that packet, but (being a router socket) also receives the ID of that client. When the server needs to send something to that client (through your design), it sends it to that ID. The client can send and receive at will, since it is a dealer socket.
Imagine you have a server which can handle only one client at a time. The server uses WSAAsyncSelect to be notified of new connections. In this case, what is the best way of handling FD_ACCEPT messages:
A > Accept the connection attempt right away but queue the client until its turn?
B > Do not accept the next connection attempt until we are done serving the currently connected client?
What do you guys think is the most efficient?
Here I describe the cons that I'm aware for both options. Hopefully this might help you decide.
A)
Upon a new client connection, it could send tons of data making your receive buffer become full, which causes unnecessary packets to be transmitted (see this). If you don't plan to receive any data from the client, shutdown receiving on that socket, thus if the client sends any data after that, the connection is reset. Moreover, if your protocol has strict rules, disconnect the client.
If the connection stays idle for too long, the system might disconnect it. To solve this, use setsockopt to set SO_KEEPALIVE on each client socket.
B)
If you don't accept the connection after a certain period (I guess the default is 60 seconds), it will timeout. In a normal (or most common) situation this indicates the server is overloaded, thus unable to answer in time. However, if the client is also designed by you, make the socket non-blocking, try to connect, then manage the timeout as you wish.
Ask yourself: what do you want the user experience to be at the other end? Do you want them to be stuck? Do you want them to time out? Do you want them to get a polite message?