Networking Reference
In-Depth Information
for(;;) {
zstr_sendm(pub, "Company1");
zstr_send(pub, "Message to be ignored.");
zstr_sendm(pub, "Company10");
zstr_send(pub, "Message to receive.");
zclock_sleep(10);
}
zsocket_destroy(context, pub);
zctx_destroy(&context);
return 0;
}
Reliability
Applications may crash unexpectedly, stop responding, can have memory leaks,
or a bug can make them run slower. In addition to problems that an application
may have, we may experience hardware failures or network problems. We need
to be sure that messages arrive at their destination no matter what problems our
infrastructure may experience. Reliability means every event is guaranteed to
arrive at its destination.
Most message queue implementations rely on a broker to have reliability, which
means messages are queued and then delivered to their destinations, whereas in
ZeroMQ, applications directly communicate with each other and messages are
resent if they are lost for some reason.
It is easy to figure out if either the server or the client stops responding when we
use the request-reply pattern. If the client or the server does not receive messages
from each other, it means there is a problem.
If you recall from Chapter 2 , Introduction to Sockets , we said that the publisher
does not know whether a subscriber is connected or not. This also means that
if a subscriber starts experiencing problems, the publisher will not know about
it and the subscriber will miss messages the publisher has been transmitting.
When it comes to reliability in the publish-subscribe pattern, we need bidirectional
communication between the publisher and the subscribers. However, the publisher-
subscriber pattern does not support bidirectional communication in ZeroMQ,
therefore, the option is to use the dealer-router pattern.
 
Search MirCeyron ::




Custom Search