summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorAmir Taaki <genjix@riseup.net>2014-03-15 15:50:28 (GMT)
committer Amir Taaki <genjix@riseup.net>2014-03-15 15:50:28 (GMT)
commit475ce06982addf7427e0386628acaed6e945552c (patch)
treeef2900d682d84fa241292d70bc5594236037f0b2
parent4b5039f04c62b16ffc2741c7af52b16c38c3b4e6 (diff)
update docs further.
-rw-r--r--doc/prot-sphinx/connecting.rst6
-rw-r--r--doc/prot-sphinx/messages.rst39
2 files changed, 8 insertions, 37 deletions
diff --git a/doc/prot-sphinx/connecting.rst b/doc/prot-sphinx/connecting.rst
index 7972ae3..2aa286a 100644
--- a/doc/prot-sphinx/connecting.rst
+++ b/doc/prot-sphinx/connecting.rst
@@ -4,10 +4,8 @@
Connecting
**********
-We use the ZeroMQ ROUTER-DEALER combination with the load balancer to perform
-asynchronous request-reply pairs. If the balancer server does not respond in
-time then the client can resend the request to a different worker. A good
-timeout value to use is 30 seconds.
+We use the ZeroMQ ROUTER-DEALER combination with the backend worker to perform
+asynchronous request-reply pairs.
To connect to the server using ZeroMQ in C++, we use:
::
diff --git a/doc/prot-sphinx/messages.rst b/doc/prot-sphinx/messages.rst
index 51a3e70..9767809 100644
--- a/doc/prot-sphinx/messages.rst
+++ b/doc/prot-sphinx/messages.rst
@@ -43,8 +43,6 @@ Imagine we send 5 messages:
socket.send(msg1, ZMQ_SNDMORE)
socket.send(msg2, ZMQ_SNDMORE)
- socket.send(msg3, ZMQ_SNDMORE)
- socket.send(msg4, ZMQ_SNDMORE)
socket.send(msg5, 0)
When the message 5 arrives to the server, then message 1-4 will be available
@@ -53,22 +51,22 @@ too for the server to receive. ZeroMQ calls this a *frame*.
Different ZeroMQ socket types can modify the frame by popping off beginning
messages before passing them to the API.
-In this document, we will imagine an abstract message type called
-:class:`obelisk_message` with the folowing methods.
+In this document, we use the class:`czmqpp::message` class
+which implements the folowing methods.
-.. cpp:function:: void obelisk_message::append(part)
+.. cpp:function:: void czmqpp::append(part)
Add a new field to the message.
-.. cpp:function:: parts_list obelisk_message::parts()
+.. cpp:function:: parts_list czmqpp::parts()
Return array of all appended parts.
-.. cpp:function:: bool obelisk_message::send(socket)
+.. cpp:function:: bool czmqpp::send(socket)
Send entire frame to socket ending on last appended part.
-.. cpp:function:: bool obelisk_message::recv(socket)
+.. cpp:function:: bool czmqpp::receive(socket)
Receive from the socket until no more messages are available in this frame.
@@ -93,24 +91,11 @@ The format of request and reply fields are very similar.
============== ====================
Request Fields Type(Size)
============== ====================
-destination worker_uuid(0 or 17)
command string
id uint32(4)
data data
============== ====================
-`destination` describes which backend worker the load balancer should direct
-the message to. If empty, then the load balancer picks a random backend
-worker. This should only be set in specific conditions where you want to
-avoid race conditions. In general it's better to write more resilient code
-that is able to handle asynchronity without demanding total consistency.
-The worker_uuid usually should be 17 bytes if specifying a destination.
-If not then it is 0 bytes (load balancer selects a worker).
-
-Note: that there is a feature to name the workers. If so, then this field
-size can vary depending on the number of bytes needed for the custom
-worker_uuid.
-
`command` is the remote method invoked on the worker.
`id` is a random value chosen by the client for corralating server replies with
@@ -121,20 +106,8 @@ requests the client sent.
============== ====================
Reply Fields Type(Size)
============== ====================
-origin worker_uuid(0 or 17)
command string
id uint32(4)
data data
============== ====================
-The only difference with replies, is the first field indicates which worker
-responded back. This is useful for if we want to batch a series of requests
-to the same worker. An example might be subscribing to an address, and fetching
-the history for the same address. Such an operation should be called on the
-same worker to guarantee against a race condition.
-
-But this feature should not be abused. Taking the example futher, if we are
-iterating a list of addresses in a wallet, we should **not** be sending all
-requests to the same worker, overloading the same worker with operations that
-aren't interlinked.
-