The Windows Sockets Lame List
or
What's Weak This Week
brought to you by
The Windows Sockets Vendor Community
- Calling connect() on a non-blocking socket, getting
WSAEWOULDBLOCK, then immediately calling recv() and expecting
WSAEWOULDBLOCK before the connection has been established.
- Lame.
- Calling select() with three empty FD_SETs and a valid
TIMEOUT structure as a sleezy delay function.
- Inexcusably lame.
- Polling with connect() on a non-blocking socket to
determine when the connection has been established.
- Dog lame.
- Assuming socket handles are always less than 16.
- Mired in a sweaty mass of lameness.
- Polling with select() and a zero timeout in Win16's
non-preemptive environment.
- Nauseatingly lame.
- Calling WSAAsyncSelect() with a zero Event mask just to
make the socket non-blocking.
- Lame. Lame. Lame. Lame. Lame.
- Telnet applications that neither enable OOBINLINE, nor read OOB
data.
- Violently lame.
- Assuming 0 is an invalid socket handle value.
- Uncontrollably lame.
- Applications that don't properly shutdown when the user closes
the main window while a blocking API is in progress.
- Totally lame.
- Out of band data.
- Intensely lame.
- Calling strlen() on a hostent structure's ip address, then
truncating it to four bytes, thereby overwriting part of
malloc()'s heap header.
- In all my years of observing lameness, I have seldom seen
something this lame.
- Polling with recv(MSG_PEEK) to determine when a complete
message has arrived.
- Thrashing in a sea of lameness.
- Martin Hall's hairline.
- Well, it's not that bad. Really. Certainly less lame than
J. Allard's hairline.
- Bounding every set of operations with calls to
WSAStartup() and WSACleanup().
- Pushing the lameness envelope.
- Ignoring API errors.
- Glaringly lame.
- Microsoft's Telnet and FTP clients.
- Indescribably lame.
- Installing an empty blocking hook that just returns FALSE.
- Floundering in an endless desert of lameness.
- Client applications that bind to a specific port.
- Suffocating in self lameness.
- Nagle challenged applications.
- Perilously teetering on the edge of a vast chasm of
lameness.
- Assuming stream sockets maintain message frame boundaries.
- Mind bogglingly lame.
- 16-bit DLLs that call WSACleanup() from their WEP.
- Inconcievably lame.
- Single byte send()s and recv()s.
- Festering in a pool of lameness.
- select().
- Self abusively lame.
- Applications that call gethostbyname() before calling
inet_addr().
- Words fail to express such all consuming lameness.
- Win32 applications that install blocking hooks.
- Grossly lame.
- Polling with ioctlsocket( FIONREAD ) on a stream socket
until a complete "message" arrives.
- Exceeds the bounds of earthly lameness.
Thanks to Keith Moore of Microsoft for putting this together. Feel free to send him additions to the list!
Mark Towfiq
(towfiq@sunsite.unc.edu)