Every couple of months someone asks: “does Indigo have an in-proc transport?” Which usually means “does Indigo have a way of sending messages so that it doesn’t ever leave the app-domain?” When this request is made of the performance team, Al Lee’s canned response is “why aren’t you using named pipes? Is it not fast enough?” Turns out that our named pipe transport has (so far) been fast enough for all the scenarios that have come to us. That is, in all of these cases, the transport is contributing very little to the overall cost.

All that aside, it’s still an interesting problem (and one I expect we’ll have to solve in the next version or two in order to expand our scope for “near” scenarios). The key thing to remember when writing any transport, even an in-appdomain one, is that boundaries must still be honored. That is, the Message must go through WriteMessage(XmlWriter) and be reconsituted through ReadMessage(XmlReader). As Yasser illustrated in his layered “protocol” channel, a sanctioned extensibility point is wrapping the Message and then performing your actions at Write or Read time. Trying to preempt this step has the same pitfalls as performing a shallow copy where you really need a deep copy: it just doesn’t work!

I do plan on mocking up an in-appdomain transport in the next few weeks. I will of course share the results here. For those interested, my plan of attack would be to first write a basic transport using binary for the encoding and a shared queue for “transport”. Future iterations would optimize both the queue and the format (since we don’t need to serialize strings or other immutable objects for example).

In the office I get all sorts of interesting questions about our transports. I’ve realized that I really should share the answers with those of you kind enough to be following along. Today’s tidbit deals with an issue encountered on the Microsoft corp-net, but there’s no reason it can’t happen outside of this deployment, especially if ISA Firewall Client is installed.

The issue is with HTTP-based Indigo clients, and manifests itself as follows:

The likely culprit is your proxy settings, which by default we pick up from the system. If you have autoproxy setup, then your Indigo client will possibly be running an autoproxy detection script, and doing all sorts of other “magic” that can interfere with accessing local sites. To correct this, you have a few options:

• Set useDefaultWebProxy=false in your binding (available on basicHttpBinding, wsHttpBinding, and httpTransportBindingElement). If you don’t want to use any proxy at all, then this is a viable option for you
• Fix your system proxy settings (i.e. turn off autoproxy if necessary, etc). This is more the solution if you’re having global HTTP issues
• Specify a proxy (and optionally proxy authentication scheme) in your binding. You need to do this in conjunction with diabling useDefaultWebProxy so that your settings actually take effect.

In my quick PDC recap I promised to post Yasser‘s demo code. So before I digress: here is the code for a protocol chunking channel.

There is a lot more refinement to be added in order to make this production-level, but it’s a great illustration of the power and flexibility of a layered channel model. We have streaming over some Indigo transports (TCP/Named Pipe datagram, and HTTP requests and responses). However, these streams suffer from connections getting dropped mid-message, and need to be secured, routed, etc at the transport layer.

Yasser’s chunking channel nicely sidesteps all of these issues. By fragmenting/reassembling at the SOAP layer, each SOAP “chunk message” can be secured using WS-Security, reliably sent using WS-RM, and even transacted using WS-Transactions. Even better, this solution works for streaming a Message over any arbitrary transport. Which means you can write a simple streaming media server by adapting the chunking channel and using it in conjunction with a Udp multicast transport. Maybe I’ll mock one up next week even 🙂

For those not on commnet, I’ve posted the slides from my PDC talk here. Enjoy!