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.
