<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>pigfoot's weblog &#187; FreeBSD</title>
	<atom:link href="http://weblog.pigfoot.org/pigfoot/category/it/unix/freebsd/feed/" rel="self" type="application/rss+xml" />
	<link>http://weblog.pigfoot.org/pigfoot</link>
	<description>We should forget about small efficiencies -- Donald Knuth</description>
	<lastBuildDate>Fri, 30 Jul 2010 02:51:24 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
		<item>
		<title>What&#8217;s the maximum value of backlog argument in listen(2) system call?</title>
		<link>http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/#comments</comments>
		<pubDate>Thu, 05 Jul 2007 05:47:47 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[C/C++]]></category>
		<category><![CDATA[Develop]]></category>
		<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Kernel]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/</guid>
		<description><![CDATA[When we write a network server program, I think lots of system calls have their own explicit parameters like socket(), bind(), accept(). But it&#8217;s very interesting when we use this system call listen(). Let&#8217;s see its prototype: int listen(int sockfd, int backlog); Yes, it&#8217;s very obvious that the first parameter is the socket fd. But, [...]]]></description>
			<content:encoded><![CDATA[<p>When we write a network server program, I think lots of system calls have their own explicit parameters like socket(), bind(), accept(). But it&#8217;s very interesting when we use this system call listen(). Let&#8217;s see its prototype:</p>
<div class="codecolorer-container text default" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><div class="text codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">int listen(int sockfd, int backlog);</div></div>
<p>Yes, it&#8217;s very obvious that the first parameter is the socket fd. But, what&#8217;s the meaning of backlog number? Some body would tell us like manpage LISTEN(2) says: &#8220;<em>The backlog parameter defines the maximum length the queue of pending connections may grow to. If a connection request arrives with the queue full the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that retries succeed.</em>&#8221;</p>
<p>From a robust server&#8217;s perspective, what&#8217;s the maximum value it should be assign? At first, I assigned very large number like 1,024 (of course, listen system call still returns successfully). After saw the manpage LISTEN(2) in <a target="_blank" href="http://en.wikipedia.org/wiki/Linux">Linux</a>, I was wrong..</p>
<div class="codecolorer-container text default" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><div class="text codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">If the socket is of type AF_INET, and the backlog argument is greater than the constant SOMAXCONN (128 in Linux 2.0 &amp; 2.2), it is silently truncated to SOMAXCONN.</div></div>
<p>It doesn&#8217;t mention kernel 2.6. But it&#8217;s fine. Let&#8217;s investigate into Linux kernel source code.</p>
<p>In Linux kernel 2.6.20.1, we can see the listen system call implementation in <a target="_blank" href="http://lxr.linux.no/source/net/socket.c#L1304">net/socket.c line 1306</a>. As it shows, the maximum number of backlog cannot be large than sysctl_somaxconn, which is assigned to SOMAXCONN. Furthermore, SOMAXCONN is defined 128 in <a target="_blank" href="http://lxr.linux.no/source/include/linux/socket.h#L226">include/linux/socket.h line 226</a>.</p>
<p>In my opinion, in Linux 2.0 to 2.6, this means backlog cannot exceed 128 by default, or it would be truncated to SOMAXCONN silently like the manpage says.</p>
<p>How about <a target="_blank" href="http://en.wikipedia.org/wiki/FreeBSD">FreeBSD</a>? We can see the note of manpage LISTEN(2) in FreeBSD 6:</p>
<div class="codecolorer-container text default" style="overflow:auto;white-space:nowrap;border:1px solid #9F9F9F;width:435px;"><div class="text codecolorer" style="padding:5px;font:normal 12px/1.4em Monaco, Lucida Console, monospace;white-space:nowrap">The listen() system call appeared in 4.2BSD. The ability to configure the maximum backlog at run-time, and to use a negative backlog to request the maximum allowable value, was introduced in FreeBSD 2.2.</div></div>
<p>I&#8217;m not very familiar with FreeBSD kernel, but let me try to trace. The start point is to check <a target="_blank" href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_syscalls.c?only_with_tag=RELENG_6">sys/kern/uipc_syscalls.c</a> of cvstag RELENG_6 in FreeBSD. We can see listen system call will invoke <em>solisten(so, uap->backlog, td)</em>. Thus, we go to <a target="_blank" href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/uipc_socket.c?only_with_tag=RELENG_6">sys/kern/uipc_socket.c</a> now to see the implementation of <em>solisten(struct socket *so, int backlog, struct thread *td)</em>. The same, the maximum value is somaxconn which is assigned to SOMAXCONN by default. Finally, we can see the value is defined in <a target="_blank" href="http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/socket.h?only_with_tag=RELENG_6">sys/sys/socket.h</a>. The value is the same as Linux &#8212; 128.</p>
<p><strong>To put it another way, if you&#8217;re writing a server program in either Linux or FreeBSD platform, it&#8217;s very appropriate to assign the value of backlog to 128. in FreeBSD, however, you can assign a negative backlog to request the maximum allowable value.</strong></p>
<p>You may ask what&#8217;s the value of backlog in popular modern server? Let&#8217;s check the source of <a target="_blank" href="http://en.wikipedia.org/wiki/Apache_HTTP_Server">Apache HTTP Server</a>. As you see in <a target="_blank" href="http://svn.apache.org/viewvc/httpd/httpd/trunk/server/listen.c?view=markup">/server/listen.c</a>, ap_listenbacklog is assigned to DEFAULT_LISTENBACKLOG which is defined 511 in <a target="_blank" href="http://svn.apache.org/viewvc/httpd/httpd/trunk/include/mpm_common.h?view=markup">/include/mpm_common.h</a>.</p>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=416&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2007/07/05/whats-the-maximum-value-of-backlog-argument-in-listen2-system-call/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>HEADS UP: FreeBSD 4.11, 6.0 EoLs coming soon</title>
		<link>http://weblog.pigfoot.org/pigfoot/2007/01/08/heads-up-freebsd-411-60-eols-coming-soon/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2007/01/08/heads-up-freebsd-411-60-eols-coming-soon/#comments</comments>
		<pubDate>Mon, 08 Jan 2007 01:28:23 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2007/01/08/heads-up-freebsd-411-60-eols-coming-soon/</guid>
		<description><![CDATA[從金山大長輩 tjs 在 CDPA 板上 post 知道的. On January 31st, FreeBSD 4.11 and FreeBSD 6.0 will have reached their End of Life dates and will no longer be supported by the FreeBSD Security Team. Users of either of these FreeBSD releases are strongly encouraged to upgrade to FreeBSD 5.5, FreeBSD 6.1, or the upcoming FreeBSD [...]]]></description>
			<content:encoded><![CDATA[<p><a target="_blank" href="http://www.freebsd.org/"><img border="0" align="right" alt="Get FreeBSD!" title="Get FreeBSD!" src="http://www.freebsd.org/logo/logo-full-thumb.png" /></a></p>
<p>從金山大長輩 <a target="_blank" href="http://portsmon.freebsd.org/portsconcordanceformaintainer.py?maintainer=tjs%40cdpa.nsysu.edu.tw">tjs</a> 在 <a href="telnet://bbs.cdpa.nsysu.edu.tw/">CDPA</a> 板上 post <a target="_blank" href="http://lists.freebsd.org/pipermail/freebsd-security/2007-January/004199.html">知道</a>的.</p>
<p>On January 31st, <a target="_blank" href="http://www.freebsd.org/">FreeBSD</a> 4.11 and FreeBSD 6.0 will have reached their End of Life dates and will no longer be supported by the <a target="_blank" href="http://www.freebsd.org/security/">FreeBSD Security Team</a>.</p>
<p>Users of either of these FreeBSD releases are strongly encouraged to upgrade to FreeBSD 5.5, FreeBSD 6.1, or the upcoming FreeBSD 6.2 before that date.</p>
<table width="100%" cellspacing="1" cellpadding="5" border="0" bgcolor="#bbbbbb">
<tbody>
<tr bgcolor="#f1f1f1">
<th>Branch</th>
<th>Release</th>
<th>Type</th>
<th>Release date</th>
<th>Estimated EoL</th>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_4</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>January 31, 2007</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_4_11</td>
<td>4.11-RELEASE</td>
<td>Extended</td>
<td>January 25, 2005</td>
<td>January 31, 2007</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_5</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>May 31, 2008</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_5_5</td>
<td>5.5-RELEASE</td>
<td>Extended</td>
<td>May 25, 2006</td>
<td>May 31, 2008</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_6</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
<td>last release + 2y</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_6_0</td>
<td>6.0-RELEASE</td>
<td>Normal</td>
<td>November 4, 2005</td>
<td>January 31, 2007</td>
</tr>
<tr bgcolor="#ffffff">
<td>RELENG_6_1</td>
<td>6.1-RELEASE</td>
<td>Extended</td>
<td>May 9, 2006</td>
<td>May 31, 2008</td>
</tr>
</tbody>
</table>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=401&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2007/01/08/heads-up-freebsd-411-60-eols-coming-soon/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>FreeBSD: Improved sendfile Facility</title>
		<link>http://weblog.pigfoot.org/pigfoot/2006/09/26/freebsd-improved-sendfile-facility/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2006/09/26/freebsd-improved-sendfile-facility/#comments</comments>
		<pubDate>Tue, 26 Sep 2006 08:36:02 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2006/09/26/freebsd-improved-sendfile-facility/</guid>
		<description><![CDATA[FreeBSD: Improved sendfile Facility, from KernelTrap. The sendfile() facility allows a regular file to be sent out to a stream socket. The system call was first implemented in FreeBSD 3.0. This provides many performance benefits for various server appliances. Andre Opperman has implemented an improved sendfile() facility for FreeBSD that has so far shown 45% [...]]]></description>
			<content:encoded><![CDATA[<p><a target="_blank" href="http://www.freebsd.org/"><img border="0" align="right" title="Get FreeBSD!" alt="Get FreeBSD!" src="http://www.freebsd.org/logo/logo-full-thumb.png" /></a></p>
<p><a target="_blank" href="http://kerneltrap.org/node/7146">FreeBSD: Improved sendfile Facility</a>, from <a target="_blank" href="http://kerneltrap.org/">KernelTrap</a>.</p>
<blockquote><p>The sendfile() facility allows a regular file to be sent out to a stream socket.</p>
<p>The system call was first implemented in FreeBSD 3.0. This provides many performance benefits for various server appliances.</p>
<p><a target="_blank" href="http://people.freebsd.org/~andre/">Andre Opperman</a> has implemented an <a target="_blank" href="http://people.freebsd.org/~andre/sendfile-20060920.diff">improved sendfile() facility</a> for FreeBSD that has so far shown 45% less CPU usage without <a target="_blank" href="http://en.wikipedia.org/wiki/TCP_segmentation_offloading">TCP segmentation offload</a> and 83% less CPU usage with TCP segmentation offload.</p>
<p>This is a great improvement over the previous implementation.</p></blockquote>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=374&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2006/09/26/freebsd-improved-sendfile-facility/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>cryptcat = netcat + encryption</title>
		<link>http://weblog.pigfoot.org/pigfoot/2006/08/20/cryptcat-netcat-encryption/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2006/08/20/cryptcat-netcat-encryption/#comments</comments>
		<pubDate>Sun, 20 Aug 2006 03:28:04 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[Gentoo]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2006/08/20/cryptcat-netcat-encryption/</guid>
		<description><![CDATA[在看 Gentoo 的 portage log 時, 看到一個還蠻有趣的軟體, 叫做 cryctcat (portage/net-analyzer/cryptcat , ports/net/cryptcat). 雖然整體功能來說, 我覺得還是 socat (portage/net-misc/socat, ports/net/socat) 比較強, 不過就編密這方面, 因為 socat 是利用 OpenSSL 來達成這個效果, 就 netcat 簡而易用的角度, 不如用 cryptcat 所採用的 Twofish 這種 symmetric key block cipher 來的簡單易用了. 原先利用 netcat 來傳檔的方法如下: MachineA: nc -l 12345 < file.orig MachineB: nc MachineA.IP 12345 > file.sent.by.MachineA 要改成 MachineA: cryptcat [...]]]></description>
			<content:encoded><![CDATA[<p>在看 <a target="_blank" href="http://www.gentoo.org/">Gentoo</a> 的 <a target="_blank" href="http://gentoo-portage.com/">portage log</a> 時, 看到一個還蠻有趣的軟體, 叫做 <a target="_blank" href="http://farm9.org/Cryptcat/">cryctcat</a> (portage/net-analyzer/cryptcat , ports/net/cryptcat).</p>
<p>雖然整體功能來說, 我覺得還是 <a target="_blank" href="http://www.dest-unreach.org/socat/">socat</a> (portage/net-misc/socat, ports/net/socat) 比較強, 不過就編密這方面, 因為 socat 是利用 <a target="_blank" href="http://www.dest-unreach.org/socat/doc/socat.html#ADDRESS_OPENSSL_CONNECT">OpenSSL</a> 來達成這個效果, 就 netcat 簡而易用的角度, 不如用 cryptcat 所採用的 <a target="_blank" href="http://en.wikipedia.org/wiki/TwoFish">Twofish</a> 這種 <a target="_blank" title="Symmetric key algorithm" href="http://en.wikipedia.org/wiki/Symmetric_key_algorithm">symmetric key</a> <a target="_blank" title="Block cipher" href="http://en.wikipedia.org/wiki/Block_cipher">block cipher</a> 來的簡單易用了.</p>
<p>原先利用 netcat  來傳檔的方法如下:</p>
<p>MachineA:</p>
<pre>nc -l 12345 < file.orig</pre>
<p>MachineB:
</pre>
<pre>nc MachineA.IP 12345 > file.sent.by.MachineA</pre>
<p>要改成</p>
<p>MachineA:</p>
<pre>cryptcat -l -p 12345 < file.orig</pre>
<p>MachineB:
</pre>
<pre>cryptcat MachineA.IP 12345 > file.sent.by.MachineA</pre>
<p>這樣就會利用預設的密碼 metallica, 透過 Twofish 加密. 當然, 也可以用 -k 這個 option 來改變預設的密碼 ;-)</p>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=331&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2006/08/20/cryptcat-netcat-encryption/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>FreeBSD starts to support XFS and ReiserFS</title>
		<link>http://weblog.pigfoot.org/pigfoot/2005/06/13/freebsd-starts-to-support-xfs-and-reiserfs/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2005/06/13/freebsd-starts-to-support-xfs-and-reiserfs/#comments</comments>
		<pubDate>Mon, 13 Jun 2005 03:27:06 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2005/06/13/freebsd-starts-to-support-xfs-and-reiserfs/</guid>
		<description><![CDATA[cvs commit log of adding files in ports for sysutils/xfsprogs. New port for utilities for manipulating XFS filesystems. Originally ported by Alexander Kabaev (kan at freebsd.org) as part of the XFS for FreeBSD project and handed over to me for maintainership. cvs commit log of adding files in src for sys/gnu/reiserfs. Import of ReiserFS filesystem [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://lists.freebsd.org/pipermail/cvs-all/2005-June/123376.html">cvs commit log</a> of adding files in ports for sysutils/xfsprogs.<br />
New port for utilities for manipulating <a href="http://oss.sgi.com/projects/xfs/">XFS filesystems</a>. Originally ported by Alexander Kabaev (kan at freebsd.org) as part of the <a href="http://people.freebsd.org/~rodrigc/xfs/">XFS for FreeBSD project</a> and handed over to me for maintainership.</p>
<p><a href="http://lists.freebsd.org/pipermail/cvs-all/2005-May/121352.html">cvs commit log</a> of adding files in src for sys/gnu/reiserfs.<br />
Import of <a href="http://www.namesys.com/">ReiserFS filesystem</a> support (currently limited to read-only on i386).</p>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=33&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2005/06/13/freebsd-starts-to-support-xfs-and-reiserfs/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>FreeBSD 6.0 code freeze</title>
		<link>http://weblog.pigfoot.org/pigfoot/2005/06/08/freebsd-60-code-freeze/</link>
		<comments>http://weblog.pigfoot.org/pigfoot/2005/06/08/freebsd-60-code-freeze/#comments</comments>
		<pubDate>Wed, 08 Jun 2005 06:35:53 +0000</pubDate>
		<dc:creator>pigfoot</dc:creator>
				<category><![CDATA[FreeBSD]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[Unix]]></category>

		<guid isPermaLink="false">http://weblog.pigfoot.org/pigfoot/2005/06/08/freebsd-60-code-freeze/</guid>
		<description><![CDATA[FreeBSD 6.0 code freeze, from OSNews. FreeBSD 6.0 schedule: June 10, 2005 &#8211; Feature freeze + code slush July 10, 2005 &#8211; RELENG_6 branch August 1, 2005 &#8211; RELENG_6_0 branch August 15, 2005 &#8211; 6.0-RELEASE]]></description>
			<content:encoded><![CDATA[<p><a href="http://www.osnews.com/story.php?news_id=10773">FreeBSD 6.0 code freeze</a>, from <a href="http://www.osnews.com/">OSNews</a>.</p>
<p>FreeBSD 6.0 schedule:</p>
<ul>
<li>June 10, 2005 &#8211; Feature freeze + code slush</li>
<li>July 10, 2005 &#8211; RELENG_6 branch</li>
<li>August 1, 2005 &#8211; RELENG_6_0 branch</li>
<li>August 15, 2005 &#8211; 6.0-RELEASE</li>
</ul>
<img src="http://weblog.pigfoot.org/pigfoot/?ak_action=api_record_view&id=21&type=feed" alt="" />]]></content:encoded>
			<wfw:commentRss>http://weblog.pigfoot.org/pigfoot/2005/06/08/freebsd-60-code-freeze/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
