aboutsummaryrefslogtreecommitdiff
path: root/syscalls.html
blob: 6bbb07408e7fde351b710d3489b21d3f3a6ed166 (plain) (blame)
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
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
<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>
		<a href="trg.c">tiny response generation</a>
		(<a href="_trg/trg.c.strace.cygwin.windows10.log.txt">log</a>):
		We see 1 call to setsockopt. This is followed by a send of
		the size 99 (the header). Then follows another setsockopt,
		followed by another call to send (the body).
	</td>
      </tr>
      <tr>
        <td>
		<a href="mrg.c">modest response generation</a>
		(<a href="_mrg/mrg.c.debian.strace.log.txt">log</a>):
		We see 1 call to setsockopt() after receiving the GET
		request (TCP_CORK).
		Then we send the header.
		We see 6 calls to setsockopt(): TCP_CORK, TCP_NODELAY,
		TCP_NODELAY, TCP_CORK, TCP_CORK, TCP_NODELAY.
		Then the body is send,
		We see 2 more setsockopt() calls: TCP_CORK, TCP_NODELAY.
	</td>
        <td>
		<a href="mrg.c">modest response generation</a>
		(<a href="_mrg/mrg.c.freebsd.truss.log.txt">log</a>):
		After receiving the GET request, we see 1 call to
		setsockopt() (TCP_NODELAY).
		Then the header is send.
		We see 1 call to setsockopt() (TCP_NODELAY).
		Then the body is send.
	</td>
        <td>
		<a href="mrg.c">modest response generation</a>
		(<a href="_mrg/mrg.c.netbsd.ktruss.log.txt">log</a>):
		After receiving the GET request, we see 1 setsockopt() call
		which is followed by sending the header.
		This is followed by 2 calls to setsockopt().
		After this, the body is send, followed by another call to
		setsockopt().
	</td>
        <td>
		<a href="mrg.c">modest response generation</a>:
		<br>
		no data.
	</td>
        <td>
		<a href="mrg.c">modest response generation</a>
		(<a href="_mrg/mrg.c.cygwin.windows10.strace.log.txt">log</a>):
		We see 2 calls to setsockopt related to the socket we use,
		each one of them before the respective send() is called.
	</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>
		<a href="response_generation_sendfile.c">response generation using sendfile()</a>
		(<a href="_rgs/response_generation_sendfile.c.freebsd.truss.log.txt">log</a>):
		We see 2 calls to setsockopt. One TCP_NODELAY afer
		receiving the GET request. One TCP_NODELAY after sending
		the header. The last one is followed by the body being
		send.
	</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>
		<a href="response_generation_sendfile.c">response generation using sendfile()</a>
		(<a href="_rgs/response_generation_sendfile.c.strace.cygwin.windows10.log.txt">log</a>):
		We see 1 call to setsockopt(), followed by a send() with size 99 (the header).
		This is followed by 1 call to setsockopt(), and one more call to send() with size 1
		(the body).
	</td>
      </tr>
      <tr>
        <td>other</td>
        <td>other</td>
        <td>other</td>
        <td>other</td>
        <td>other</td>
      </tr>
    </table>
  </body>
</html>