forked from booksbyus/zguide
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes.txt
80 lines (57 loc) · 2.42 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
.end
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?
+++ Decentralised Logging System
- pubsub log events
- filter levels
- capture in log files or memory
- dynamic graphing
- log file cycling
+++ Timer Service
- ticks, 1/10, 1/100, etc.
+++ Disconnected Security
Chapter 9 topics
- the wire level protocol
- a minimal TCP stack
- internals of 0MQ
- generate bindings in
Python
C#
Java
Ruby
++++ Reliable Pipeline (Harmony Pattern)
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 Harmony 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