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
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
<!ENTITY % global_entities SYSTEM '../entities/global.entities'>
%global_entities;
]>
<chapter id="architecture">
<chapterinfo>
<author>
<firstname>Dan</firstname><surname>Shearer</surname>
</author>
<pubdate> November 1997</pubdate>
</chapterinfo>
<title>Samba Architecture</title>
<sect1>
<title>Introduction</title>
<para>
This document gives a general overview of how Samba works
internally. The Samba Team has tried to come up with a model which is
the best possible compromise between elegance, portability, security
and the constraints imposed by the very messy SMB and CIFS
protocol.
</para>
<para>
It also tries to answer some of the frequently asked questions such as:
</para>
<orderedlist>
<listitem><para>
Is Samba secure when running on Unix? The xyz platform?
What about the root priveliges issue?
</para></listitem>
<listitem><para>Pros and cons of multithreading in various parts of Samba</para></listitem>
<listitem><para>Why not have a separate process for name resolution, WINS, and browsing?</para></listitem>
</orderedlist>
</sect1>
<sect1>
<title>Multithreading and Samba</title>
<para>
People sometimes tout threads as a uniformly good thing. They are very
nice in their place but are quite inappropriate for smbd. nmbd is
another matter, and multi-threading it would be very nice.
</para>
<para>
The short version is that smbd is not multithreaded, and alternative
servers that take this approach under Unix (such as Syntax, at the
time of writing) suffer tremendous performance penalties and are less
robust. nmbd is not threaded either, but this is because it is not
possible to do it while keeping code consistent and portable across 35
or more platforms. (This drawback also applies to threading smbd.)
</para>
<para>
The longer versions is that there are very good reasons for not making
smbd multi-threaded. Multi-threading would actually make Samba much
slower, less scalable, less portable and much less robust. The fact
that we use a separate process for each connection is one of Samba's
biggest advantages.
</para>
</sect1>
<sect1>
<title>Threading smbd</title>
<para>
A few problems that would arise from a threaded smbd are:
</para>
<orderedlist>
<listitem><para>
It's not only to create threads instead of processes, but you
must care about all variables if they have to be thread specific
(currently they would be global).
</para></listitem>
<listitem><para>
if one thread dies (eg. a seg fault) then all threads die. We can
immediately throw robustness out the window.
</para></listitem>
<listitem><para>
many of the system calls we make are blocking. Non-blocking
equivalents of many calls are either not available or are awkward (and
slow) to use. So while we block in one thread all clients are
waiting. Imagine if one share is a slow NFS filesystem and the others
are fast, we will end up slowing all clients to the speed of NFS.
</para></listitem>
<listitem><para>
you can't run as a different uid in different threads. This means
we would have to switch uid/gid on _every_ SMB packet. It would be
horrendously slow.
</para></listitem>
<listitem><para>
the per process file descriptor limit would mean that we could only
support a limited number of clients.
</para></listitem>
<listitem><para>
we couldn't use the system locking calls as the locking context of
fcntl() is a process, not a thread.
</para></listitem>
</orderedlist>
</sect1>
<sect1>
<title>Threading nmbd</title>
<para>
This would be ideal, but gets sunk by portability requirements.
</para>
<para>
Andrew tried to write a test threads library for nmbd that used only
ansi-C constructs (using setjmp and longjmp). Unfortunately some OSes
defeat this by restricting longjmp to calling addresses that are
shallower than the current address on the stack (apparently AIX does
this). This makes a truly portable threads library impossible. So to
support all our current platforms we would have to code nmbd both with
and without threads, and as the real aim of threads is to make the
code clearer we would not have gained anything. (it is a myth that
threads make things faster. threading is like recursion, it can make
things clear but the same thing can always be done faster by some
other method)
</para>
<para>
Chris tried to spec out a general design that would abstract threading
vs separate processes (vs other methods?) and make them accessible
through some general API. This doesn't work because of the data
sharing requirements of the protocol (packets in the future depending
on packets now, etc.) At least, the code would work but would be very
clumsy, and besides the fork() type model would never work on Unix. (Is there an OS that it would work on, for nmbd?)
</para>
<para>
A fork() is cheap, but not nearly cheap enough to do on every UDP
packet that arrives. Having a pool of processes is possible but is
nasty to program cleanly due to the enormous amount of shared data (in
complex structures) between the processes. We can't rely on each
platform having a shared memory system.
</para>
</sect1>
<sect1>
<title>nbmd Design</title>
<para>
Originally Andrew used recursion to simulate a multi-threaded
environment, which use the stack enormously and made for really
confusing debugging sessions. Luke Leighton rewrote it to use a
queuing system that keeps state information on each packet. The
first version used a single structure which was used by all the
pending states. As the initialisation of this structure was
done by adding arguments, as the functionality developed, it got
pretty messy. So, it was replaced with a higher-order function
and a pointer to a user-defined memory block. This suddenly
made things much simpler: large numbers of functions could be
made static, and modularised. This is the same principle as used
in NT's kernel, and achieves the same effect as threads, but in
a single process.
</para>
<para>
Then Jeremy rewrote nmbd. The packet data in nmbd isn't what's on the
wire. It's a nice format that is very amenable to processing but still
keeps the idea of a distinct packet. See "struct packet_struct" in
nameserv.h. It has all the detail but none of the on-the-wire
mess. This makes it ideal for using in disk or memory-based databases
for browsing and WINS support.
</para>
</sect1>
</chapter>
|
