You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/introduction.md
+4-2Lines changed: 4 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -165,11 +165,12 @@ NetMQ comes with several options that will effect how things work.
165
165
166
166
Depending on the type of sockets you are using, or the topology you are attempting to create, you may find that you need to set some ZeroMQ options. In NetMQ this is done using the `NetMQSocket.Options` property.
167
167
168
-
Here is a listing of the available properties that you may set on a `NetMQSocket`. It is hard to say exactly which of these values you may need to set, as that obviously depends entirely on what you are trying to achieve. All I can do is list the options, and make you aware of them. So here they are:
168
+
Here is a listing of the available options that you may set on a `NetMQSocket`. It is hard to say exactly which of these values you may need to set, as that obviously depends entirely on what you are trying to achieve. All I can do is list the options, and make you aware of them. So here they are:
169
169
170
170
+`Affinity`
171
171
+`BackLog`
172
172
+`CopyMessages`
173
+
+`Correlate`
173
174
+`DelayAttachOnConnect`
174
175
+`Endian`
175
176
+`GetLastEndpoint`
@@ -185,6 +186,7 @@ Here is a listing of the available properties that you may set on a `NetMQSocket
185
186
+`ReceiveBuffer`
186
187
+`ReconnectInterval`
187
188
+`ReconnectIntervalMax`
189
+
+`Relaxed`
188
190
+`SendHighWaterMark`
189
191
+`SendTimeout`
190
192
+`SendBuffer`
@@ -194,4 +196,4 @@ Here is a listing of the available properties that you may set on a `NetMQSocket
194
196
+`TcpKeepaliveInterval`
195
197
+`XPubVerbose`
196
198
197
-
We will not be covering all of these here, but shall instead cover them in the areas where they are used. For now just be aware that if you have read something in the <ahref="http://zguide.zeromq.org/page:all"target="_blank">ZeroMQ guide</a> that mentions some option, that this is most likely the place you will need to set it/read from it.
199
+
We will not be covering all of these here, but shall instead cover them in the areas where they are used. For now just be aware that if you have read something in the <ahref="http://zguide.zeromq.org/page:all"target="_blank">ZeroMQ guide</a> that mentions some option, that this is most likely the place you will need to set it/read from it. Also, the socket options are described in the <ahref="http://api.zeromq.org/master:zmq-setsockopt"target="_blank">zmq_setsockopt</a> documentation.
Copy file name to clipboardExpand all lines: docs/request-response.md
+39-4Lines changed: 39 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ Anyway we digress, this post is about Request/Response, so lets continue to look
12
12
13
13
Request / Response pattern is a configuration of two NetMQ sockets working harmoniously together. This combination of sockets are akin to what you might see when you make a web request. That is, you make a request and you expect a response.
14
14
15
-
`RequestSocket` and `ResponseSocket` are **synchronous**, **blocking**, and throw exceptions if you try to read messages in the wrong order.
15
+
`RequestSocket` and `ResponseSocket` are **synchronous**, **blocking**, and throw exceptions if you try to read messages in the wrong order (however; see below for socket options that allow relaxing of this strict rule).
16
16
17
17
The way you should work with connected `RequestSocket` and `ResponseSocket`s is as follows:
18
18
@@ -21,7 +21,7 @@ The way you should work with connected `RequestSocket` and `ResponseSocket`s is
21
21
3. The `ResponseSocket` sends the response message
22
22
4. The `RequestSocket` receives the message from the `ResponseSocket`
23
23
24
-
Believe it or not you have more than likely already seen this example on numerous occasions as it is the simplest to demonstrate.
24
+
Believe it or not, you have more than likely already seen this example on numerous occasions as it is the simplest to demonstrate.
25
25
26
26
Here is a small example where the `RequestSocket` and `ResponseSocket`s are both in the same process, but this could be easily split between two processes. We are keeping this as simple as possible for demonstration purposes.
27
27
@@ -50,7 +50,7 @@ When you run this demo code you should see something like this:
50
50
51
51
## Request/Response is blocking
52
52
53
-
As stated above `RequestSocket` and `ResponseSocket` are blocking, which means any unexpected send or receive calls to **WILL** result in exceptions. Here is an example of just such an exception.
53
+
As stated above `RequestSocket` and `ResponseSocket` are blocking, which means any unexpected send or receive calls to **WILL** result in exception being thrown. Here is an example of just such an exception.
54
54
55
55
In this example we try and call `Send()` twice from the `RequestSocket`
56
56
@@ -60,4 +60,39 @@ Or how about this example where we try and call `RecieveString()` twice, but the
60
60
61
61

62
62
63
-
So be careful what you do with the Request/Response pattern, the devil is in the detail.
63
+
So be careful what you do with the Request/Response pattern; the devil is in the details.
64
+
65
+
## Relaxing the strict req/rep pattern
66
+
67
+
If you have set the Relaxed and Correlate options for your request socket, you can send
68
+
multiple times from a request socket before a response arrives.
69
+
When you get a response back, that response will be a reply to the last sent request. Please
70
+
note, however, that this does not absolve the ResponseSocket from servicing all of the requests
71
+
that have come in; the only difference is that on the Requesting side, you will "see" only
72
+
one of the responses; the one for the latest request.
73
+
74
+
This functionality is useful for situations in which the responder might unexpectedly disconnect,
75
+
as well as being able to reliably query to see if a response socket is available before sending
76
+
a real request. See the <ahref="http://api.zeromq.org/master:zmq-setsockopt"target="_blank">documentation for the native ZMQ library</a> at for more details.
0 commit comments