End to end (E2E) tracing is a very useful tool for tracking down bugs that occur in a distributed system (such as Indigo). You can learn more about it from a new Channel 9 video on WCF tracing that features Laurence from the Tracing product team.

This question came up a few times while I was away for my honeymoon: “If I am using BasicHttpBinding or WsHttpBinding, how do I setup the credentials for my proxy?”

In my earlier post on HTTP proxies I noted that all of our transport security implementations (including HTTP proxy authentication) leverage the shared WCF-wide credential provisioning framework. As a result, it’s pretty straightforward to configure your proxy credentials. I think what trips people up is that we don’t have a separate “ProxyCredentials” object. Rather, both the proxy authentication and the ultimate server authentication access credentials from the same location (such as ChannelFactory.Credentials).

One limitation of this approach is that if you are using the same authentication scheme for your proxy and your server, then you have to use the same credentials (e.g. the same username and password for Basic Auth). This was a concious tradeoff we made for V1. If any of you have a scenario that is broken by this limitation I’d love to hear about it.

In my description of HostNameComparisonMode I neglected to explicitly mention how the wildcard-ness affects your port#. In short, we will ignore the port# in our match if you have chosen StrongWildcard or WeakWildcard, and we will include the port# in our match if you choose Exact.

This behavior is especially useful when using network monitoring intermediaries. Let’s say you have an intermediary listening on TCP port 8080 that forwards traffic to your service on port 8081. The Via on the wire for net.tcp would be net.tcp://mymachine:8080/a/b/. When this intermediary forwards the packets to your service listening at port 8081, the request would succeed only for Wildcard bindings.

Actually setting up a intermediary takes a few more tweaks to your service and client that I’ll go into more detail about next week.

When listening on any socket-based protocol (http, net.tcp, UDP, SMTP, etc), there are ultimately two items that contribute to where we listen: IP Address and Port.

Your port# is usually specified in the URI of your endpoint (see RFC 2396, section 3.2.2). If a port# is not specified then each URI scheme has the option of supporting a default port# (HTTP uses 80, HTTPS uses 443, net.tcp uses 808, etc.). You can also configure a WCF endpoint to listen on
any available port# for client-side or Discovery/registry purposes.

For WCF transports, your IP Address is specified in the same manner, though this may not be obvious on the surface. If you specify an IP Address in the hostname of your URI, then we will listen on that exact IP Address. For example, net.tcp://127.0.0.1/myservice/ will only receive traffic received on the IPv4 localhost interface.

If you do not specify an IP Address in your endpoint URI, then the transport will provide a set of default IP Addresses for listening. For net.tcp, we will listen on IP_ANY (both V4 and V6 where available). For http, we will use the http.sys IP Listen List, which also defaults to INADDR_ANY and INADDR6_ANY.

For routing traffic, wildcard semantics are in effect, which means that net.tcp://localhost/a/b and net.tcp://127.0.0.1/a/b will match the same set of incoming Messages. The difference is that the first URI is exposed to all interfaces/IP Addresses while the second URI is limited solely to 127.0.0.1.

Now that the July CTP is public, I can divulge the details of a feature that I added to WCF in April.

In PDC ’05 we showed how you can use WCF extensibility to send “POX” (Plain Old Xml) Messages via our runtime. However, it took some magical incantations to enable. These including setting HttpMappingMode on the HttpTransportBindingElement, and writing a custom encoder that only writes out the body of the Message.

In July CTP, you now get 1st class support for POX-style Messages. To accomplish this, we added new Addressing and Envelope Versions (AddressingVersion.None and EnvelopeVersion.None). I’m also happy to report the obsolescence and removal of HttpMappingMode (nee MapAddressingHeadersToHttpHeaders for those former Beta 1 users who have been following along).

AddressingVersion.None means that your addressing information (To, Action, etc) is transmitted out of band from the Envelope. One example of this type of addressing is BasicHttpBinding — the <To> is sent as the HTTP Request-Uri, and the <Action> is sent out as either the SOAP-Action (in SOAP 1.1), or as a parameter to the content-type (in SOAP 1.2). If a particular binding requires WS-Addressing, then they can throw on Send() for Messages with AddressingVersion.None

EnvelopeVersion applies to the basic structure of the Message. This is where SOAP can come in to play. By default, the EnvelopeVersion of a Message is EnvelopeVersion.Soap12. SOAP 1.2 includes (among other things), support for Headers, and an outer <Envelope> tag. To “wash off” the SOAP from the Message (thanks Don), you should create a Message with EnvelopeVersion.None. When using such Messages, you cannot add any Headers other than <To> and <Action>. <To> and <Action> are “special” since they are intrinsics used by the runtime system. <To> is used by default for addressing dispatch, and <Action> is used by default for Operation dispatch. Some transports (such as our HTTP Transport) will strip these header values out and lift them into their “framing layer” (i.e. the goo we put around a Message to conform to the HTTP protocol).

For our programming model, AddressingVersion and EnvelopeVersion are packaged together into a single MessageVersion that is assigned to a Message or a Binding. Enabling simple POX messaging is now simply a matter of setting up an HTTP binding on your service with a TextEncoder that uses MessageVersion.None (or messageVersion=”none” in config-speak). Viola! No SOAP!

NOTE: see here for more information about the breaking changes between Beta 2 and the June CTP.

In case you haven’t noticed, Nicholas has been blogging up a storm since his arrival at Microsoft — I highly recommend a subscription to his feed.

Nicholas has a great post explaining the various knobs available to be tweaked at the Transport layer. He also explains the post-RC0 changes we made to connection pool settings and throttling.

For developer settings, you shouldn’t need to touch the defaults, but for live deployments you will find these knobs quite useful. Our guidance on actual tuning is currently, uhm, thin but I’ve promised Christian that I’ll remedy that after I’ve beaten the last few WCF stress bugs into submission 🙂

The other day I was asked “why should I use IsOneWay=true on my OperationContract? What does it actually do or optimize?”. In other words, what are the technical differences between:

[OperationContract]
void Send(MyMessage message);

and:
[OperationContract(IsOneWay=true)]
void Send(MyMessage message);

The first difference is semantics — even though you have a void method, if you don’t mark the Operation with IsOneWay then we will wait for an ACK/NACK reply. There are a few other behavioral changes when you choose IsOneWay:

1. The service will release the connection (or complete the HTTP request/response by replying with null, etc) before dispatching to user code. If the operation is not marked with IsOneWay then our Dispatcher won’t reply until the Operation has completed
2. ServiceModel Runtime will ask for IOutputChannel first, before falling back to IRequestChannel or IDuplexSessionChannel if IOutputChannel isn’t available. This allows the underlying stack to make optimizations on send/receive.
3. Service Model Faults will not be returned, so Exceptions caused by the Message-level processing are not propagated to the client (though it’s still possible to receive a framing-level fault such as an HTTP status code error).

In general, you should have your methods represent their semantic usages. This will help your overall design and allow the system to know best how to adapt to your intended usage. So if you are writing a true one-way notification (or building upon one-way methods for a duplex contract), be sure to remember the IsOneWay=true annotation.

Today we released our first Indigo CTP under the fresh .Net Framework label here. For 2k3 and XP users, download away (this build does not work with Vista Beta 2).

One of the key improvements in WCF is the concept of multiple “endpoints” at a Service. Last week (when I was offsite with a customer) I had an interesting revelation. While we cover the “ABCs” of Indigo (Address + Binding + Contract == Endpoint) in every introductory talk, many users don’t fully grasp the flexibility multiple endpoint support offers. This is most acute with regards to hosting in IIS, when multiple endpoint support involves “URI space beyond the file”.

For example, let’s say I have an Image Download Service hosted at image.svc. For interop purposes I expose a BasicHttp endpoint. I also add a second endpoint that uses a binary encoding instead of text. I provide a relative address of “binary” to this endpoint for addressing purposes. In this case my interop endpoint is exposed as:
http://kennyw.com/vdir/image.svc

And the binary endpoint is addressible as:
http://kennyw.com/vdir/image.svc/binary

Yes, that’s “/binary” after the filename.

The relevant piece of config for such as service (assuming you have a “binaryHttpBinding” defined in your bindings section) looks like:

<system.serviceModel>
 <services>
  <service name="Microsoft.ServiceModel.Samples.ImageService">
    <endpoint address=""
              binding="basicHttpBinding"
              contract="Microsoft.ServiceModel.Samples.IImageService" />

    <endpoint address="binary"
              binding="binaryHttpBinding"
              contract="Microsoft.ServiceModel.Samples.IImageService" />
  </service>
 </services>
</system.servicemodel>