lame-list.html

SDK FAQ集

Reason: <code>WEP()</code> is lame, ergo depending on it is
lame. Seriously, 16-bit Windows did not guarantee that <code>WEP()</code>
would always be called, and the Windows subsystem was often in
such a hairy state that doing <i>anything</i> in <code>WEP()</code> was
dangerous.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Stay away from <code>WEP()</code>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Single byte <code>send()</code>s and <code>recv()</code>s. <i>Festering
in a pool of lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: Couple one-byte sends with Nagle disabled, and you have at
best a 40:1 overhead-to-data ratio. Can you say wasted bandwidth? I
thought you could.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

As for one-byte receives, think of the effort and inefficiency
involved with trying to drink a Guinness Stout through a hypodermic
needle. That's about how your application would feel "drinking" data
one-byte at a time.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Consider Postel's <a
href="../../rfcs/official.html#rfc793">RFC 793</a> words to live by:
"Be conservative in what you do, be liberal in what you accept from
others." In other words, send modest amounts, and receive as much as
possible.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<a name=item23> <li><code>select()</code>. <i>Self abusively lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: Consider the steps involved in using <code>select()</code>. You
need to use the macros to clear the 3 <code>fd_set</code>s, then set the
appropriate <code>fd_set</code>s for each socket, then set the timer, then
call <code>select()</code>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Then after <code>select()</code> returns with the number of sockets that
have done something, you need to go through all the <code>fd_set</code>s
and all the sockets using the macros to find the event that occurred,
and even then the (lack of) resolution is such you need to infer the
event from the current socket state.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Use asynchronous operation mode
(e.g. <code>WSAAsyncSelect()</code> or <code>WSAEventSelect()</code>).<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Applications that call <code>gethostbyname()</code> before calling
<code>inet_addr()</code>. <i>Words fail to express such all-consuming
lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: Some users prefer to use network addresses rather than
hostnames at times. The Winsock 1.1 specification does not say what
<code>gethostbyname()</code> should do with an IP address in standard ASCII
dotted IP notation. As a result, it may succeed and do an (unnecessary)
reverse-lookup, or it may fail.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: With any destination input by a user<img src="../bitmaps/waist-dot.gif" alt="--" width=14 height=6 hspace=2>which may
be a hostname <i>or</i> dotted IP address<img src="../bitmaps/waist-dot.gif" alt="--" width=14 height=6 hspace=2>you should call
<code>inet_addr()</code> <i>first</i> to check for an IP address, and if
that fails call <code>gethostbyname()</code> to try to resolve it.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Furthermore, in some applications, you may want to explicitly check
the input string for the broadcast address "255.255.255.255," since the
return value from <code>inet_addr()</code> for this address is the same as
<code>SOCKET_ERROR</code>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Win32 applications that install blocking hooks. <i>Grossly
lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: Besides yielding to other applications (<a href="#item17">see
item 17</a>), blocking hook functions were originally designed to allow
concurrent processing within a task while there was a blocking operation
pending. In Win32, there's threading.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Use threads.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Polling with <code>ioctlsocket(FIONREAD)</code> on a stream socket
until a complete "message" arrives. <i>Exceeds the bounds of earthly
lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason and Alternative: <a href="#item12">See item 12</a>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Assuming that a UDP datagram of any length may be
sent. <i>Criminally lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: Various networks all have their limitations on maximum
transmission unit (MTU). As a result, fragmentation will occur, and
this increases the likelihood of a corrupted datagram (more pieces to
lose or corrupt). Also, the TCP/IP service providers at the receiving
end may not be capable of re-assembling a large, fragmented datagram.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: check for the maximum datagram size with the
<code>SO_MAX_MSG_SIZE</code> socket option, and don't send anything
larger. Better yet, be even more conservative. A max of 8K is a good
rule-of-thumb.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Assuming the UDP transmissions (especially multicast transmissions)
are reliable. <i>Sinking in a morass of lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: UDP has no reliability mechanisms (that's why we have TCP).<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Use TCP and keep track of your own message boundaries.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Applications that require vendor-specific extensions, and cannot
run (or wore yet, load) without them. <i>Stooping to unspeakable depths
of lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: If you can't figure out the reason, it's time to hang up
your keyboard.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Have a fallback position that uses only base capabilities
for when the extension functions are not present.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

<li>Expecting errors when UDP datagrams are dropped by the sender,
receiver, or any router along the way. <i>Seeping lameness from every
crack and crevice.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Reason: UDP is unreliable. TCP/IP stacks don't have to tell you when
they throw your datagrams away (a sender or receiver may do this when
they don't have buffer space available, and a receiver will do it if
they cannot reassemble a large fragmented datagram.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>

Alternative: Expect to lose datagrams, and deal. Implement reliability
in your application protocol, if you need it (or use TCP, if your
application allows it).<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all> 

</ol>

<p><font size=-1>Copyright owned by the authors of the Lame List items,
including, but not necessarily limited to, the people mentioned in the
introductory matter at the beginning of this article.</font></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="../articles/effective-tcp.html">&lt;&lt; Effective TCP/IP</a>
		</td>

		<td align=right>
		    <a href="../articles/debugging-tcp.html">Debugging TCP &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>