advanced.html

SDK FAQ集

the system's networking configuration.</p>

<p>The <a href="examples/getmac-rpc.html">second method</a> depends on a
property of the Remote Procedure Call specification that says that the
last 6 bytes of a UUID will be derived from the hardware address of the
local machine's network adapter. In the case of Ethernet (the common
case), this is the MAC address. The major problem with this method is
that it will only return one address; if there is more than one Ethernet
network adapter in the system, this method won't let you get that second
adapter's address.</p>

<p>The descriptions introducing each example go into these issues
further.</p>

<p>The <a href="#snmp">SNMP</a> item above links to an article that
contains another method for getting MAC addresses.</p>





<a name="maxsockets"></a>
<h5>4.9 - How many simultaneous sockets can I have open with Winsock?</h5>

<p>On Win9x machines, there's quite-low limit imposed by the kernel:
100 connections. You can increase this limit by editing the registry
key HKLM\System\CurrentControlSet\Services\VxD\MSTCP\MaxConnections. On
Windows 95, the key is a DWORD; on Windows 98, it's a string. I've seen
some reports of instability when this value is increased to more than
a few times its default value.</p>

<p>The rest of this discussion will cover only Windows NT and Windows
2000. These systems have much higher intrinsic capabilities, and thus
allow you to use many more sockets. But, the Winsock specification does
not set a particular limit, so the only sure way to tell is to try it
on all the Winsock stacks you plan on supporting.</p>

<p>Beyond that vague advice, things get more complicated. The simplistic
test is to just write a program that just opens sockets, to see where
the program stops running: <a href="examples/get-sockets.html">[C++
Example]</a>.</p>

<p>The above program isn't terribly realistic. I've seen it grab more
than 30,000 sockets before failing on Windows NT 4.0. Anecdotal evidence
from the Winsock 2 mailing list puts the real limit much lower, typically
4,000 to 16,000 sockets, even on NT systems with hundreds of megabytes of
physical memory. The difference is that the example program just grabs
socket handles, but does not actually create connections with them or
tie up any network stack buffers.</p>

<p>According to people at Microsoft, the WinNT/Win2K kernel allocates
sockets out of the non-paged memory pool. (That is, memory that cannot
be swapped to the page file by the virtual memory subsystem.) The size
of this pool is necessarily fixed, and is dependent on the amount of
physical memory in the system.</p>

<p>On Intel x86 machines, the non-paged memory pool stops growing at
1/8 the size of physical RAM, with a hard maximum of 128 megabytes. The
hard limit is 256 megabytes on Windows 2000. Thus for NT 4, the size of
the non-paged pool stops increasing once the machine has 1 GB of RAM. On
Win2K, you hit the wall at 2 GB.</p>

<p>The amount of data associated with each socket varies depending on how
that socket's used, but the minimum size is around 2 KB. Overlapped
I/O buffers also eat into the non-paged pool, in blocks of 4 KB. (4
KB is the x86's memory management unit's page size.) Thus a simplistic
application that's regularly sending and receiving on a socket will tie
up at least 10 KB of non-pageable memory.</p>

<p>Assuming that simple case of 10 KB of data per connection, the
theoretical maximum number of sockets on NT 4.0 is about 12,800s, and
on Win2K 25,600.</p>

<p>I have seen reports of a 64 MB Windows NT 4.0 machine hitting the wall
at 1,500 connections, a 128 MB machine at around 4,000 connections, and
a 192 MB machine maxing out at 4,700 connections. It would appear that
on these machines, each connection is using between 4 KB and 6 KB. The
discrepancy between these numbers and the 10 KB number above is probably
due to the fact that in these servers, not all connections were sending
and receiving all the time. The idle connections will only be using about
2 KB each.</p>

<p>So, adjusting our "average" size down to 6 KB per socket,
NT 4.0 could handle about 21,800 sockets and Win2K about 43,700
sockets. The largest value I've seen reported is 16,000 sockets
on Windows NT 4.0.</p>

<p>There's one more complication to keep in mind: your server program
will not be the only thing running on the machine. If nothing else,
there will be core OS services running. These other programs will be
competing with yours for space in the non-paged memory pool.</p>





<a name="fdsetsize"></a>
<h5>4.10 - Can I change FD_SETSIZE to make <tt>select()</tt> wait on more than 64 sockets?</h5>

<p>You can, but in practice it may not work. Several common Winsock
stacks and Layered Service Providers limit themselves internally to the
default value of FD_SETSIZE, 64. However, you can write a test program
to try this on the systems you plan on supporting, to see if they are not
limited. Also, you can always send each group of 64 sockets to a different
thread, so that several calls to <code>select()</code> can occur
simultaneously.</p>





<a name="forceif"></a>
<h5>4.11 - How do I make Winsock use a specific network interface?</h5>

<p>On a machine with multiple network interfaces (a modem for dialup
Internet and a LAN card, for example), it can sometimes be useful to
force Winsock to use a specific interface. Before I go into how, keep
in mind that the routing layer of the stack exists to handle this for
you. If your setup isn't working the way you want, maybe you just need to
change the routing tables. (This is done with the "route" and "netstat"
command-line programs on Microsoft stacks.)</p>

<p>There are two common reasons why you might want to force Winsock to
use a particular network interface. The first is when you only want
your server program to handle incoming connections on a particular
interface. For example, if you have an NT machine set up as an Internet
gateway, and it also runs a server that you only want internal LAN users
to be able to access, you will want to set it to only listen on the
LAN interface. The other reason is that you have two or more possible
outgoing routes, and you want your client program to connect using a
particular one without the routing layer getting in the way.</p>

<p>You can do both of these things with the <code>bind()</code>
function. Using one of the "get my IP addresses" <a
href="examples/index.html">examples</a>, you can present your user with
a list of possible addresses. Then they can pick the appropriate
address to use, which your program will use in the <code>bind()</code>
call. Obviously, this is only feasible for programs intended for advanced
users.</p>

<p>Incidentally, this is how virtual hosting on the Internet works. A
single server is set up with a single network card but several IP
addresses. Windows NT/2000 can do this, but Win9x cannot. To set this
up in NT, go into the TCP/IP area of the Network control panel,
and then click the Advanced button. IIRC, you can enter up to five
network addresses per interface in NT Workstation, perhaps more in NT
Server.</p>

<p>Note that this information does not apply to the Windows 95/98
multihomed computer <a href="intermediate.html#dunbug">DUN bug</a>. This
problem cannot be fixed by <code>bind()</code>ing to the LAN interface
in an effort to force the OS to use it exclusively. The problem is due
to a bug in the OS's name resolver. See the DUN bug FAQ item for
workarounds.</p>





<a name="tcpbits"></a>
<h5>4.12 - What is the { SYN, ACK, FIN, RST } bit?</h5>

<p>See the FAQ article <a href="articles/debugging-tcp.html">Debugging
TCP</a>.</p>





<a name="clientbind"></a>
<h5>4.13 - Is it a bad idea to <tt>bind()</tt> to a particular port in a client program?</h5>

<p>It's occasionally justifiable, but most of the time it's a very
bad idea.</p>

<p>I've only heard of two good uses of this feature. The first is
when your program needs to bind to a port in a particular range. Some
implementations of the Berkeley "r commands" (e.g. rlogin, rsh, rcp,
etc.) do this for security purposes. Because only the superuser on
a Unix system can bind to a low-numbered port (1-1023), such an r
command tries, sequentially, to bind to one of the ports in this range
until it succeeds. This allows the remote server to surmise that if the
connection is coming from a low-numbered port, the remote user must be
a superuser. (This port range limit also applies to Windows NT and
Windows 2000, but <i>not</i> to Windows 9x.)</p>

<p>The second justifiable example is FTP in its "receive file" mode:
it binds to a random port and then tells the file server to "send the
file to this port". This is justifiable because it arguably cleans up the
protocol, and the FTP client doesn't need to bind to any particular port,
it just needs to bind to <i>a</i> port. (Incidentally, it does this by
binding to port 0 <img src="./bitmaps/waist-dot.gif" alt="-" width=7 height=6 hspace=2> the stack chooses an available port when you
do this.) This is also justifiable because the FTP client is acting as a
server in this case, so it makes sense that it has to bind to a port.</p>

<p>By contrast, it is almost always an error to bind to a
<i>particular</i> port in a client. (Notice that both of the above
examples are flexible about the ports they bind to.) To see why this
is bad, consider a web browser. They often create several connections
to download a single web page, one each to fetch all of the individual
pieces of the page: images, applets, sound clips, etc. If they always
bound to a particular local port, they could only have one connection
going at a time. Also, you couldn't have a second instance of the web
browser downloading another page at the same time.</p>

<p>That's not the biggest problem, though. When you close a TCP
connection, it goes into the <tt>TIME_WAIT</tt> state for a short period
(between 30 and 120 seconds, typically), during which you cannot reuse
that connection's "5-tuple:" the combination of {local host, local port,
remote host, remote port, transport protocol}. (This timeout period
is a feature of all correctly-written TCP/IP stacks, and is covered
in <a href="../rfcs/official.html#rfc793">RFC 793</a> and especially
<a href="../rfcs/official.html#rfc1122">RFC 1122</a>.) In practical
terms, this means that if you bind to a specific port all the time,
you cannot connect to the same host using the same remote port until
the <tt>TIME_WAIT</tt> period expires. I have personally seen anomalous
cases where the <tt>TIME_WAIT</tt> period does not occur, but when this
happens, it's a bug in the stack, not something you should count on.</p>

<p>For more on this matter, see the <a
href="articles/lame-list.html#item18">Lame List</a>.</p>



		</td>
	</tr>
</table>


<!--  ---- Document Footer ----  -->

<hr noshade size=1 color=#404040>

<table cellpadding=5 cellspacing=0 border=0 width=95% align=center> 
	<tr>
		<td align=left>
		    <a href="intermediate.html">&lt;&lt; Intermediate Winsock Issues</a>
		</td>

		<td align=right>
		    <a href="resources/index.html">Winsock Resources &gt;&gt;</a>
		</td>
	</tr>

	<tr>
		<td align=left>
			<i>Last modified on 29 April 2000 at 15:52 UTC-7</i>
		</td>

		<td align=right>
			<font size=-1>Please send corrections to <a href="mailto:[e-mail]">[e-mail]</a>.</font>
		</td>
	</tr>	
</table>	

<table cellpadding=5 cellspacing=0 border=0 width=95% align=center> 
	<tr>
		<td align=left width=33%>
			<font size=-1>
				<a href="index.html"><b>&lt;</b> Go to the main FAQ page</a>
			</font>
		</td>

		<td width=33%>
			<font size=-1>
			<center>
				<a href="http://www.cyberport.com/~tangent/programming"><b>&lt;&lt;</b> Go to my Programming pages</a>
			</center>
			</font>
		</td>

		<td align=right width=33%>
			<font size=-1>
				<a href="http://www.cyberport.com/~tangent/"><b>&lt;&lt;&lt;</b> Go to my Home Page</a>
			</font>
		</td>
	</tr>	
</table>	


</body>
</html>