📄 lame-list.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"><html lang="en"><head><title>Winsock Programmer's FAQ: Articles</title><link rel="Stylesheet" type="text/css" href="../faq.css"></head><body bgcolor="#ffffee" text="#000000" link="#491e00" vlink="#7d2e01" alink="#da7417"><!-- ---- Header Bar ---- --><table border="0" width="95%" bgcolor="#006000" cellpadding="5" cellspacing="3" align="center"> <tr> <td align="left" bgcolor="#e0e0c0"> <font size="2" face=Verdana,Arial,Helvetica> <b><a href="../articles/effective-tcp.html"><<</a></b> </font> </td> <td align="center"> <font face=Verdana,Arial,Helvetica color="#ffffee"> <p align=center class=bigger3><b> Winsock Programmer's FAQ<br> Section 7: Articles<br> </b></p> </font> </td> <td align="right" bgcolor="#e0e0c0"> <font size="2" face=Verdana,Arial,Helvetica> <b><a href="../articles/debugging-tcp.html">>></a></b> </font> </td> </tr></table><!-- ---- Body Table ---- --><table width="95%" border="0" cellpadding="10"> <tr valign="top"> <td><H3>The Lame List</H3><h4>Introduction</h4><p>I have reproduced The Lame List here because it is so valuable. Thistext is cut-and-pasted directly from Appendix C of version 2.2.2 of the<i>Windows Sockets 2 Application Programming Interface</i>. The listoriginally started out as a list of complaints by Winsock stack vendorsabout wrongheaded applications<img src="../bitmaps/waist-dot.gif" alt="--" width=14 height=6 hspace=2>we won't name names here. Despitethat, these items are still valuable because newbie Winsockers still makethe same wrongheaded mistakes. Avoiding the items on this list will takeyou a long way along the road toward Winsock guruhood.</p><h5>The original introduction to the List:</h5><p class=inset>Keith Moore of Microsoft gets the credit for startingthis, but other folks have begun contributing as well. Bob Quinn,from sockets.com, is the kind soul who provided the elaborations onwhy these things are lame and what to do instead. This is a snapshotof the list as we went to print (plus a few extras thrown in at thelast minute).</p><p>This version of the List is slightly different from the original:I have changed some punctuation, minor bits of phrasing, etc. And,of course, I have added all the pretty HTML formatting.</p><h4>The Windows Sockets Lame List<br>(or What's Weak This Week)</h4><p><i>Brought to you by The Windows Sockets Vendor Community</i></p><ol><li>Calling <code>connect()</code> on a non-blocking socket, getting<code>WSAEWOULDBLOCK</code>, then immediately calling <code>recv()</code>and expecting <code>WSAEWOULDBLOCK</code> before the connection has beenestablished. <i>Lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: This assumes that the connection will never be establishedby the time the application calls <code>recv()</code>. Lame assumption.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: Don't do that. An application using a non-blockingsocket must handle the <code>WSAEWOULDBLOCK</code> error value, but mustnot depend on occurrence of the error.<li>Calling <code>select()</code> with three empty <code>fd_set</code>sand a valid <code>TIMEOUT</code> structure as a sleazy delayfunction. <i>Inexcusably lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: The <code>select()</code> function is intended as a networkfunction, not a general purpose timer.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: Use a legitimate system timer service.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><li>Polling with <code>connect()</code> on a non-blocking socket todetermine when the connection has been established. <i>Dog lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: The Winsock 1.1 spec does not define an error for<code>connect()</code> when a non-blocking connection is pending, so theerror value returned may vary.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: Using asynchronous notification of connection completionis the recommended alternative. An application that prefers synchronousoperation mode could use the <code>select()</code> function (but <ahref="#item23">see item 23</a>).<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Non-Alternative: Changing a non-blocking socket to blocking modeto block on <code>send()</code> or <code>recv()</code> is even more lame thanpolling on <code>connect()</code>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><a name=item4> <li>Assuming socket handles are always less than16. <i>Mired in a sweaty mass of lameness.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: The only invalid socket handle value is defined by the<code>winsock.h</code> file as <code>INVALID_SOCKET</code>. Any other valuethe <code>SOCKET</code> type can handle is fair game, and an application<i>must</i> handle it. In any case, socket handles are supposed to beopaque, so applications shouldn't depend on specific values for anyreason.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: Expect a socket handle of any value, including 0. Anddon't expect socket handle values to change with each successive call to<code>socket()</code> or <code>WSASocket()</code>. Socket handles may be reusedby the Winsock implementation.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><li>Polling with <code>select()</code> and a zero timeout in Win16'snon-preemptive environment. <i>Nauseatingly lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: With any non-zero timeout, <code>select()</code> will callthe current blocking hook function, so an application anticipatingan event will yield to other processes executing in a 16-bit Windowsenvironment. However, with a zero timeout an application will not yieldto other processes, and may not even allow network operations to occur(so it will loop forever).</P>Alternative: Use a small non-zero timeout. Better yet, use asynchronousnotification instead of using <code>select()</code>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><li>Calling <code>WSAAsyncSelect()</code> with a zero Event mask just tomake the socket non-blocking. <i>Lame. Lame. Lame. Lame. Lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: <code>WSAAsyncSelect()</code> is designed to allow an applicationto register for asynchronous notification of network events. The Winsock1.1 specification didn't specify an error for a zero event mask, butmay interpret it as an invalid input argument (so it may fail with<code>WSAEINVAL</code>), or silently ignore the request.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: To make a socket non-blocking without registering forasynchronous notification, use <code>ioctlsocket(FIONBIO)</code>. That'swhat it's for.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><a name="item7"> <li>Telnet applications that neither enable<code>SO_OOBINLINE</code>, nor read OOB data. <i>Violently lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: It is not uncommon for Telnet servers to generate urgentdata, like when a Telnet client will send a Telnet BREAK command orInterrupt Process command. The server then employs a "Synch" mechanismwhich consists of a TCP Urgent notification coupled with the TelnetDATA MARK command. If the telnet client doesn't read the urgent data,then it won't get any more normal data. Not ever, ever, ever, ever.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Alternative: Every telnet client should be able to read and/ordetect OOB data. They should either enable inline OOB data by calling<code>setsockopt() SO_OOBINLINE</code>, or use <code>WSAAsyncSelect()</code>(or <code>WSAEventSelect()</code>) with <code>FD_OOB</code> or <code>select()</code>using <code>except_fds</code> to detect OOB data arrival, and call<code>recv()/WSARecv()</code> with <code>MSG_OOB</code> in response.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><li>Assuming 0 is an invalid socket handle value. <i>Uncontrollablylame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason and Alternative: <a href="#item4">See item 4</a>.<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all><li>Applications that don't properly shut down when the user closes themain window while a blocking API is in progress. <i>Totally lame.</i><img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>Reason: Winsock applications that don't close sockets, and call<code>WSACleanup()</code>, may not allow a Winsock implementation to reclaimresources used by the application. Resource leakage can eventually resultin resource starvation by all other Winsock applications (i.e. networksystem failure).<img src="../bitmaps/dot-clear.gif" alt="" width=1 height=30 align=top> <br clear=all>⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -