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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
<html>
<head>
</head>
<body>
<style>
table {
border-collapse: collapse;
width: 100%;
}
td, th {
border: 1px solid black;
}
</style>
<h1><a href="https://d.n0.is/pub/libmicrohttpd/gsoc2019/syscalls.html">SYSCALLS</a></h1>
<p>
<b>LEGEND:</b>
</p>
<ul>
<li>
columns: Operatings Systems
<li>
rows: tests, with link to code
</ul>
<p>
<b>TESTS:</b>
</p>
<ul>
<li>
continuous response generation (ensure no constant
setsockopt() calls during transmission)
<li>
tiny response generation (fits in one packet, including
header, ensure one packet and sending without corking)
<li>
modest response generation (header first, then body, ensure
last part of body is sent without corking)
<li>
response generation using sendfile() (making sure that after
last write operation the packet is sent without corking, no
unnecessary setsockopts)
</ul>
<p>
<b>OBJECTIVE:</b><br><br>
To list and analysis the current results, ie prior to patching lmhd source
</p>
<table>
<tr>
<th>Debian Linux</th>
<th>FreeBSD</th>
<th>NetBSD</th>
<th>OS X</th>
<th>cygwin x64 (under Windows 10)</th>
</tr>
<tr>
<td>
<a href="inc.c">
continuous response generation
</a>:
<a href="crg/inc.c.debian.strace.log.txt">
(log)
</a>
<br>
In the strace log it can be observed that on Debian
the following pattern occurs:
setsockopt, sendto, setsockopt, setsockopt, setsockopt,
setsockopt, setsockopt, setsockopt.
This switches the client's socket between the following flags:
TCP_CORK -> TCP_CORK -> TCP_NODELAY -> TCP_NODELAY ->
TCP_CORK -> TCP_CORK -> TCP_NODELAY.
After this, the body of the message is sent. This again is
followed after the last message ("\r\n") by 2 setsockopt() calls
with the first having the flag TCP_CORK, the second the flag
TCP_NODELAY.
</td>
<td>
<a href="inc.c">
continuous response generation
</a>:
<a href="crg/inc.c.freebsd.truss.log.txt">
(log)
</a>
<br>
The log of truss under FreeBSD shows
a comparable pattern: setsockopt is called 3 times.
</td>
<td>
<a href="inc.c">
continuous response generation
</a>:
<a href="crg/inc.c.netbsd.ktruss.log.txt">
(log)
</a>
<br>
The log of ktruss under NetBSD shows that again we have 2
calls to setsockopt after application start.
</td>
<td>
<a href="inc.c">
continuous response generation
</a>:
<br>
No data.
</td>
<td>
<a href="inc.c">
continuous response generation
</a>:
<a href="crg/inc.c.cygwin.strace.log.txt">
(log)
</a>
<br>
The log of cygwin shows 1 call of main to setsockopt
in the beginning
(111 279601 [main] a 268 cygwin_setsockopt: 0 = setsockopt(5, 65535, 0x4, 0xFFFFCA10, 4)).
After this, MHD-single calls setsockopt 2 times (setsockopt, followed by
cygwin_send, followed by another setsockopt call).
The pattern in cygwin is comparable to the ktruss log in NetBSD, where
we see a setsockopt, sendto, setsockopt at the beginning of the log.
</td>
</tr>
<tr>
<td>
<a href="trg.c">tiny response generation</a>
(<a href="_trg/trg.c.debian.strace.log.txt">log</a>):
After receiving the GET request, we see 1
setsockopt call (TCP_CORK). The header is send.
This is followed by 6 setsockopt calls:
TCP_CORK, TCP_NODELAY, TCP_NODELAY, TCP_CORK,
TCP_CORK, TCP_NODELAY. The body is send.
Then we see 2 final setsockopt calls: TCP_CORK,
TCP_NODELAY.
</td>
<td>
<a href="trg.c">tiny response generation</a>
(<a href="_trg/trg.c.freebsd.truss.log.txt">log</a>):
There are 2 setsockopt calls. The first sets TCP_NODELAY.
It is followed directly by the header being send.
The second setsockopt call sets TCP_NODELAY.
</td>
<td>
<a href="trg.c">tiny response generation</a>
(<a href="_trg/trg.c.netbsd.ktruss.log.txt">log</a>):
After receiving the GET request, we see 1 call to setsockopt,
followed by sending the header. The header is immediately followed
by 2
calls to setsockopt, then the body is send ("b"), immediately
follows a call to setsockopt.
</td>
<td>
<a href="trg.c">tiny response generation</a>:
<br>
no data
</td>
<td>tiny response generation</td>
</tr>
<tr>
<td>modest response generation</td>
<td>modest response generation</td>
<td>modest response generation</td>
<td>
<a href="mrg.c">modest response generation</a>:
<br>
no data.
</td>
<td>modest response generation</td>
</tr>
<tr>
<td>
<a href="response_generation_sendfile.c">response generation using sendfile()</a>
(<a href="_rgs/response_generation_sendfile.c.debian.strace.log.txt">log</a>):
The test had to be updated for Debian to work, so we are
reading a prepared file which exists, contrary to the earlier
NetBSD test.
After receiving the GET request, we see 1 call to
setsockopt (TCP_CORK) immediately before the header is
send.
Then we see 6 calls to setsockopt:
TCP_CORK, TCP_NODELAY, TCP_NODELAY, TCP_CORK, TCP_CORK,
TCP_NODELAY. sendfile is called. setsockopt is called to
set TCP_NODELAY. the filedescriptor is closed. setsockopt
is called with TCP_NODELAY.
</td>
<td>response generation using sendfile()</td>
<td>
<a href="response_generation_sendfile.c">response generation using sendfile()</a>
(<a href="_rgs/response_generation_sendfile.c.netbsd.ktruss.log.txt">log</a>):
After receiving the GET request, the file with
the content "a" is created.
We see 1 call to setsockopt just before the header is send.
Immediatelly after we see another setsockopt call. The file
is read, then we see another setsockopt call followed by
a sendto of "a".
</td>
<td>
<a href="response_generation_sendfile.c">response generation using sendfile()</a>:
<br>
no data.
</td>
<td>response generation using sendfile()</td>
</tr>
<tr>
<td>other</td>
<td>other</td>
<td>other</td>
<td>other</td>
<td>other</td>
</tr>
</table>
</body>
</html>
|
