August, 2004

Larry Osterman's WebLog

Confessions of an Old Fogey
  • Larry Osterman's WebLog

    What's wrong with this code, part 5

    • 53 Comments

    So there was a reason behind yesterday’s post about TransmitFile, it was a lead-in for “What’s wrong with this code, part 5”.

    Consider the following rather naïve implementation of TransmitFile (clearly this isn’t the real implementation; it’s just something I cooked up on the spot):

    bool TransmitTcpBuffer(SOCKET socket, BYTE *buffer, DWORD bufferSize)
    {
          DWORD bytesWritten = 0;
          do
          {
                DWORD bytesThisWrite = 0;
                if (!WriteFile((HANDLE)socket, &buffer[bytesWritten], bufferSize - bytesWritten, &bytesThisWrite, NULL))
                {
                      return false;
                }
                bytesWritten += bytesThisWrite;
          } while (bytesWritten < bufferSize);
          return true;
    }

    bool MyTransmitFile(SOCKET socket, HANDLE fileHandle, BYTE *bufferBefore, DWORD bufferBeforeSize, BYTE *bufferAfter, DWORD bufferAfterSize)
    {
          DWORD bytesRead;
          BYTE  fileBuffer[4096];

          if (!TransmitTcpBuffer(socket, bufferBefore, bufferBeforeSize))
          {
                return false;
          }

          do
          {
                if (!ReadFile(fileHandle, (LPVOID)fileBuffer, sizeof(fileBuffer), &bytesRead, NULL))
                {
                      return false;
                }
                if (!TransmitTcpBuffer(socket, fileBuffer, bytesRead))
                {
                      return false;
                }

          } while (bytesRead == sizeof(fileBuffer));

          if (!TransmitTcpBuffer(socket, bufferAfter, bufferAfterSize))
          {
                return false;
          }
          return true;
    }

    Nothing particular exciting, but it’s got a big bug in it.  Assume that the file in question is opened for sequential I/O, that the file pointer is positioned correctly, and that the socket is open and bound before the API is called.  The API doesn’t close the socket or file handle on failure; it’s the responsibility of the caller to do so (closing the handles would be a layering violation).  The code relies on the fact that on Win32 (and *nix) a socket is just a relabeled file handle.

    As usual, answers and kudos tomorrow.

     

     

     

  • Larry Osterman's WebLog

    My favorite APIs: TransmitFile

    • 11 Comments

    Back in NT 3.5ish, Microsoft first deployed IIS, our web server.  The people working on it very quickly realized that the server wasn’t up to snuff performance-wise.

    A bit of profiling and they realized the problem – the application was doing:

                CreateFileEx(inputFile);
    while (!eof(inputFile))
    {
        ReadFile(inputFile, &inputBuffer);
        WriteFile(socket, inputBuffer);
    }

    The problem was the transfer through inputBuffer.  The file was in the cache in the kernel (from the read file), but the data had to be transferred from the cache, into the user mode inputBuffer, then back into the kernel to the in-kernel TCP buffer.  All those copies were making the web server CPU bound.

    Needless to say, this wasn’t a good situation, so for NT 3.51, a new system call was added: TransmitFile.  TransmitFile was tailored for the web server, because it allowed the user to specify a set of user buffers that were to be prepended and appended to the file before and after the transfer.  So a web server could put the HTTP response headers in the prepend portion, and any trailing data needed in the append portion.

    It turns out that TransmitFile was absolutely perfect for Exchange, because we were able to take advantage of it for both our POP3 and IMAP servers – we set the prepend portion to the +OK response for POP3, and the append portion to “<crlf>.<crlf>” for POP3 for example.

    Now TransmitFile can be tricky to use – you need to lock the TCP/IP connection before and afterwards – if you attempt to send data on the connection before the TransmitFile completes, the results are “undefined” – it might work, you might get the data interleaved with the file contents.

     

  • Larry Osterman's WebLog

    Waste, Fraud, and Abuse

    • 17 Comments

    Thanks For Letting Us Know

    Vernon Blake, an engineer at the Alabama Department of Transportation, was upset that it was an office joke that his boss spent most of his workday playing computer games. Since he was the department's network administrator, Blake installed "spyware" software on his boss's computer to get evidence; 70 percent of the 414 resulting screen shots taken over a seven-month period showed Solitaire on the boss's screen. Blake sent the evidence to managers. The result: his boss, assistant bureau chief George Dobbs, received a letter from his boss complimenting his "work ethic above reproach" but gently pointing out his game-playing was unacceptable. For his efforts, Blake was fired, ending his 21-year career. His offense? Installing software on department computers "without authority or permission." (Montgomery Advertiser)...On the bright side, with Blake gone Dobbs now has something to do.

     © 2004 This is True, reprinted with permission from the author.

     

    It turns out that Vernon Blake has a web site: http://www.aldotwaste.com

    It’s fascinating.  I’m not sure if his firing was justified or not (he presents a good case that his actions in installing the monitoring program wasn’t in violation of department policy), but Valorie and I had a long discussion about the slap on the wrist that the manager received.  She feels that it was outrageously lenient; my take is that the letter was a fairly measured reprimand, if the supervisor was really was effective in his job.  On the other hand, there is a clear indication that his game playing was causing morale issues, and compromising the supervisor’s ability to manage his organization.

    But what SHOULD the reaction of an employee in an IT department be when he discovers that a supervisor in a division is spending time playing games instead of doing his job?  Is it appropriate to install spyware on his computer to document the abuse before blowing the whistle?  The courts have held that it’s ok for a manager (or corporation) to install spyware on employees’ computers, but what about the other way around?

    Edit: Removed extraneous break.

     

  • Larry Osterman's WebLog

    Comment Policy is now up.

    • 0 Comments

    I got nailed by a new blog-spammer yesterday, so it's my turn to follow KC and Raymond and post a comment policy.

    My new comment policy can be found here.  It's unlikely to change anything, except for the blog-spam, I've never had any issues with anyone commenting on my post that violated it, but...

     

Page 2 of 2 (29 items) 12