Communication overhead

The other, most obvious concern you face with networked programming is dealing with the openness of open communication. That property means that you'll have to spend a substantial amount of time familiarizing yourself with the specific messaging standards of different communication protocols (which I'll cover in depth in this book). There's an immense amount of organization necessary to cram data into well-formed packets, with appropriate header information to tell your software when to start and when to stop reading from your connection to get the full, uninterrupted binary stream and convert that back into meaningful data structures in your code. It's a headache just describing the process.

In locally hosted code, you have the benefit of sharing DLLs of your libraries among consumer applications to facilitate a shared contract for data structures. You could communicate with other software on your system through the filesystem itself. You could just use the systems, file-access APIs to expose all the nuts and bolts of how much data exists in your message, what the encoding of that data is, and expose it through random access into the file.

With a network, you have to give enough context for someone else to make sense of your message with the message itself. And you have to communicate that context in a way that a consumer could understand it before they have that context. Once again, the .NET libraries will come to your rescue here, providing easy-to-use classes exposing standardized headers and message formats to keep your code clear of that overhead.