Brad Fitzpatrick (brad) wrote,
Brad Fitzpatrick
brad

buffered networkstream: stupid

Sometimes writing a big post is all it takes to jog the brain a bit.

I realized I don't need a BufferedStream wrapping my NetworkStream to the client. My original rationale was that, even though I was sending 4k at a time to my network stream, I mistakenly thought (without really thinking) that those went right to the client, spliced on MTU boundaries as necessary by the kernel.

So I was fearing things like: 2 full packets, 1 half full one, 2 full, 1 half, repeat...

But no... I didn't think. The kernel already does all that buffering. (or can, that is, and does by default)

What I should've been looking at is C#'s Socket class to be able to do things like enable/disable Nagel's algorithm, and things like Linux's cork/uncork or BSD's push/nopush. Who knows what C#/Windows calls it.

Yeah, so it all clicked that the BufferedStream is really just there for reducing syscalls for tiny IO, and reducing disk writes when the underlying stream is a file or disk-based. But when I already do very few large writes, the extra buffering is useless.

Time to remove code! (always fun)

Oh, btw: O'Reilly Network Safari Bookshelf is really damn cool. The interface, search, and everything are just great. And the book "C# Essentials" is a lot more direct and hard-core than "Programming C#". I can only fear what "Learning C#" is like.
Tags: tech
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 0 comments