forked from booksbyus/zguide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
notes.txt
121 lines (84 loc) · 3.38 KB
/
notes.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
- initialize client
- simplest
- recalculate cache after each file change
- option to load cache into message
- fmq_dir_cache
- refreshes .cache on disk
- returns hash table
- load cache from disk
- fmq_dir_cache returns / updates it
- new file
-> update into cache
-> save whole cache
- icanhaz
-> send cache to server
- optional
-> resync command from API
filemq
client says
I want everything
I already have this, this, this
filename, size
.filemq_dir
log files, first time
include file sha1 as sent by server
server sends sha1 together with file chunk
Chapter 5:
- durable subscribers
+++ Content Distribution
We now have a robust framework for creating groups of nodes and letting them chat to each other. Next step is to allow them to distribute content.
+++ Security
+++ Bridging
(More coming soon)
++++ The Messaging Layer
So we've solved discovery, presence, connectivity, and simulation. Next on our list: security, unicast messaging, and multicast messaging.
++++ File Transfer
Take FILEMQ and plug into this framework.
Notes for The Guide
==1742== Syscall param write(buf) points to uninitialised byte(s)
==1742== at 0x5372100: __write_nocancel (syscall-template.S:82)
==1742== by 0x5306312: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1289)
==1742== by 0x53061D9: new_do_write (fileops.c:543)
==1742== by 0x5307944: _IO_do_write@@GLIBC_2.2.5 (fileops.c:516)
==1742== by 0x5306E6F: _IO_file_close_it@@GLIBC_2.2.5 (fileops.c:170)
==1742== by 0x52FB2CF: fclose@@GLIBC_2.2.5 (iofclose.c:62)
==1742== by 0x4060FF: fmq_file_test (fmq_file.c:342)
==1742== by 0x4021E6: main (fmq_selftest.c:38)
==1742== Address 0x4027000 is not stack'd, malloc'd or (recently) free'd
FILE *handle = fopen ("testdata", "w");
zmq_msg_t msg;
zmq_msg_init_size (&msg, 100);
size_t items = fwrite (zmq_msg_data (&msg), 1, 100, handle);
fclose (handle);
zmq_msg_close (&msg);
+++ Bridging
- why and how
- semantic compatibility
- example 0MQ to HTTP
- using zxxx library?
+++ Disconnected Security
Chapter 9 topics
- the wire level protocol
- a minimal TCP stack
- internals of 0MQ
- generate bindings in
Python
C#
Java
Ruby
++++
0MQ's pipeline pattern (using PUSH and PULL sockets) is reliable to the extent that:
* Workers and collectors don't crash;
* Workers and collectors read their data fast enough to avoid queue overflows.
As with all our reliability patterns, we'll ignore what happens if an upstream node (the ventilator for a pipeline pattern) dies. In practice a ventilator will be the client of another reliability pattern, e.g. Clone.
The Xyz pattern takes pipeline and makes it robust against the only failure we can reasonably handle, namely workers and (less commonly) collectors that crash and lose messages or work.
- assume workers are idempotent
- assume batch size is known in advance (because...)
- assume memory enough to hold full batch
- batch: start (address of collector), tasks, end
- messages numbered 0 upwards inside batch
- assume multiple ventilators for same cluster
- assume collector talks to ventilator, (not same to allow walk-up-and use by ventilators)
- call ventilator the 'client'
- if task missing, resend
- if end of batch missing, resend from last response