Encryption is counterproductive for compression if the two features aren't used together correctly. Generally, you want to compress first and then encrypt. This is the order that naturally happens when you compress at the encoding level and encrypt at the transport level. You tend to get disadvantageous results if you encrypt first and then compress. This order can happen when you encrypt early on, such as when you use message security with transport compression, or if you attempt to apply compression

When I create a channel to a service, how do I know when the service is ready to process the data for that channel? A channel doesn't really know what the service is doing. The service might be actively processing the data being sent over the channel. Or, the service might not. There is a constant tension in the system between components that want to push data and components that want to pull data. Components that push data actively work as long as there is data available until a back pressure builds

How do I find the address of a client connection to make a trust decision? Don't base security decisions on the perceived client address. Any address that we have comes from the underlying socket implementation and could be spoofed. The data that the socket has is sourced by the client. You should be using a source of information that has a verification process that the server trusts, such as a certificate, to distinguish clients. Next time: Reader Trends

Simplicity is elusive. A few weeks ago I learned that part of transaction flow, propagating information about the source machine between the client and server, is more complicated than I thought. It's not that the details were inherently complicated but rather that they were inconsistent. The information was passed in a certain header of the message, except when using a particular transaction protocol and transport protocol together. Someone noticed that a few bytes could be saved by optimizing this

Earlier this week a new beta release came out for Network Monitor. Although the beta has a variety of new features, the one I'm most interested in is the change to the capture engine to reduce the number of dropped frames. I've had problems in the past with missing frames in Network Monitor captures, especially for fast networks when there is a substantial CPU load. You can get the release from the Network Monitor Connect site .

Many common networking problems can be diagnosed by tracing System.Net events. This is often much easier than setting up packet captures or other software, particularly if you're working on a production machine. Since tracing is a part of the framework, it works almost everywhere just by dropping some additional configuration. Here's an example of a complete configuration file for turning on System.Net tracing. < configuration > < system.diagnostics > < trace autoflush ="true" />

As I mentioned on the 30th anniversary of IP , an early and fundamental split was made in TCP to distinguish point-to-point messaging from end-to-end messaging. The split is based on a philosophy that the communication endpoints should be in control and that there should be a minimal amount of functionality and responsibility distributed along the communication path in between. The end-to-end philosophy shows up in how TCP systems perform throttling. Duplication of throttling makes the system more

Today's post is more observational than informational. Enjoy. It's sometimes possible to write XML without having an XML library. If your XML documents are sufficiently similar and templated, then you can craft validly formed XML through little more than string manipulation. The trivial case is where the string is a constant expression and the XML document is actually the same every time through. The more interesting case is where the string has many spots where you can fill-in-the-blank with arbitrary

On January 1st, 1983 the ARPANET officially switched over from using NCP (Network Control Protocol) to TCP/IP (Transmission Control Protocol over Internet Protocol). This followed a year where the ARPANET supported a mix of NCP and TCP/IP machines using relay servers that supplied Telnet, FTP, and mail services across the two protocols. While the Telnet and FTP services were very similar between the two protocols, mail service was much improved thanks to the recently developed SMTP standard. Before

There needs to be some concept of cleanup that takes place when an asynchronous request can't be completed. For example, when a service is shut down or a socket is closed you know that any asynchronous operation waiting on that resource will never get a result. Something needs to happen to the asynchronous operations to prevent them from lingering forever. The asynchronous callback pattern has no built-in concept for cancelling a request that you made previously. Even if you build in the concept