Last Saturday, Driftwood played at Siam’s on Lake Union. We were accompanied by the Blue Scholars, who not only great DJs but really nice guys. The theme for the evening was “Thai me up”, and a few people really got into the leather and lace theme (pictures coming soon I promise!).
Unfortunately, we are now looking for a new guitarist. There’s no “Behind the Music” story here, just that Aaron Goldfeder (our esteemed lead guitar) has left Microsoft and is travelling the world until next October. So if you know any guitarists in Seattle, let me know! Bonus points if your guitarist can double on vocals and has some songwriting inclinations!
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).
Lauren and I have 4 sets of parents between us. When we got engaged they all asked when they would get to meet each other. Within a week my Mom, Dad, step-Mom, and step-Dad had booked plane tickets and hotel rooms for a weekend in LA. We hoped this was foreshadowing of logistical ease for the wedding (verdict is still out, but I remain hopeful).
Lauren and I flew down last night, and today was day one of three. So far it’s been quite entertaining (as LL and I expected). Less fiascos, and much more fun than the movie “Meet the Parents” (which was a waste of time). And so far no ultra-embarrassing stories (which I don’t expect to last throughout the weekend). Just a bunch of silliness and wine and vodka! 🙂
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:
System.ServiceModel.ProtocolException: The remote server returned an unexpected response: (502) ProxyError (The URL is invalid. The request was not entered correctly. Enter the correct URL and try again.) -> System.Net.WebException: The remote server returned an error: (502) bad gateway.
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!