I’ll admit it, I really enjoy food. There are times that Lauren and I spend an entire commute on food-related topics. Fortunately Lauren really enjoys food as well (she sometimes posts pictures of her meals).
Yesterday we had a fabulous meal at Vios on Capitol Hill and I decided to start blogging about my dining experiences. You can follow along, or just bookmark the main restaurant page which I will update as I post about an establishment. Mmmmm…..
To limit DoS exposure, we have a knob on all of our transports to control the size of Messages received on the wire. This way, we will only allocate a bounded amount of memory for each message. This setting is binding.MaxReceivedMessageSize in imperative code (or <binding maxReceivedMessageSize="654321"> in config). If an incoming Message is larger than MaxReceivedMessageSize, we will drop the Message (and fault the transport channel for session-ful channels).
Many of our transports/bindings also have a “MaxBufferSize” knob. For buffered transports, this value is always equal to MaxReceivedMessageSize (and the system Asserts this fact). However, for Streamed bindings (TransferMode == TransferMode.Streamed), we only need to buffer the SOAP Headers in order to generate a Message, and we can have the Body stream in on-demand. In this case, MaxBufferSize <= MaxReceivedMessageSize, and MaxReceivedMessageSize will bound the overall message, while MaxBufferSize bounds the Headers size.
One thing to note about these settings is that they are local behavioral settings. That is, they are not transmitted in Metadata. So if you generate a proxy to a service with a MaxReceivedMessageSize = 2GB, the proxy will have a default value (64K) for MaxReceivedMessageSize. This leaves control of the appropriate MaxReceivedMessageSize in the hands of the administrator to decide, and (hopefully) helps with our out-of-the-box security story.
For those who want to watch the occasional .mov file but don’t want to install quicktime on your Windows box, check out Quicktime Alternative. Cool piece of freeware.
Back from vacation and catching up on life in the rainy city (a little more rain in Seattle this time of year than Buenos Aires, go figure). While I was gone, Ed posted a good overview of the changes between Beta 1 and the November CTP. Don’t be put off by the number of renames and restructuring that has occurred, most of it is surface-level (and IMHO results in a more usable system). Enjoy!
Something we do a pretty poor job of in the November CTP but are actively working on fixing is helping users diagnose when their client and server have mismatched bindings. I often get teased that all we get back is “connection was aborted” which can mean anything from mismatched binding to my hard drive exploded. One particular exception that came up today was:
ProtocolException(“The HTTP response in the SOAP-over-HTTP one-way binding must not contain an entity body.”)
This likely means that you have WsDualHttpBinding on the client, but WsHttpBinding on the server. So your client is expecting a “202 Accepted” to signal that the one-way message was accepted, but the server is sending the method response on this back channel. We detect the mismatch and throw. Of course, our error message isn’t all that helpful. But now if someone does a web search for the exception, hopefully they can find out what went wrong 🙂 Look for a better exception message in a future drop.
I’ve been very bad about posting, my apologies. It’s been a busy few weeks since Thanksgiving. Lauren and I have been working hard on wedding plans (we recently hired a band and a florist to complete our list of core vendors). It’s pretty exciting to have all the big details finally coming together just in time for us to leave on vacation.
Which is another item that’s kept me pretty busy — final details for winter holiday in South America 🙂 Lauren and I are heading to Miami on Friday, then spending 3 weeks in Argentina and Chile. This trip has been in the works for awhile (it was originally intended as an Australia/New Zealand trip, and when that was foiled by the airline miles gods we redirected to an alternative southern hemisphere destination). I’m really excited for the vacation — it’s been over a year since our last big trip.
The first week includes Buenos Aires and Iguazu Falls. I expect we’ll get a good amount of shopping in Buenos Aires, and try to hang with the locals who start going out around 1AM. One of Lauren‘s co-workers is getting married while we’re there, so I’ll be packing my suit for an Argentinian wedding. Serendipity at its finest.
The second week we’re heading down to Northern Patagonia in Chile. We’re spending my birthday on a catamaran to the San Rafael Glacier, one of the fastest moving glaciers in the world. Then we’re indulging for the next few days at Termas de Puyuhuapi and Queulat National Park. Turns out that once you go south of Puerto Montt transportation is a little hard to come by, but the region looks stunning. So we’ll be taking planes, minibuses, and boats as necessary to make our way through the territory.
Before we leave the Austral region, we get to spend 2 days rafting class V rapids on the Rio Futeleufu. I had always dreamed of rafting the Rio Bio Bio with my father (both because the rapids looked awesome, and because the name was rad). Alas the Bio Bio was lost to the ENDESA in 1998 when they finished the Pangue dam. With the demise of the Bio Bio, the “Fu” is the latest Chilean rafting hot spot. It’s harder to get to, but supposedly well worth it. There have been rumors that the Futaleufu is next, though it’s managed to evade the hydroelectric-mongers so far and I’ll keep my fingers crossed for them. We get to spend New Year’s celebrating and camping on the river. Should be very, uhm, tribal.
The last week is in Chile’s Lakes Region. We’ll be staying in Puerto Varas and relaxing by Lake Llanquehue.
On our way back to Seattle we’re stopping in Miami for 2 days, where my very excited mother is throwing us an engagement party at her house. Hopefully we’ll have some new Argentinian duds to sport at the event 🙂
I’m down in LA for Thanksgiving with Lauren‘s family for a few days of warm weather and sleeping in (Shawnie is a big fan of late morning wakeups). Yesterday we were put to work on a Lavoie traditional sidedish: cranberry salsa. Pretty easy to make with a food processor, and so so much better than your traditional cranberry sauce. Helene found the recipe in a magazine in 2000, and still had the clipping in her kitchen. Guaranteed to spice up your mild-mannered turkeys. Enjoy!
As I implied in an earlier post, there’s a little more to the ServiceModel Channel Shapes then meets the eye. What I listed in the contract->shape mapping last week shows all the possibilities of what ServiceModel will request. However, it glosses over the process of how the channel requested is mapped to your service method. When you use ServiceModel, you get an extra layered channel at the top of your channel stack. The “Service Channel” has logic to normalize channel shapes into one-way and request reply patterns.
For example, let’s say you have method such as:
OperationContract]void Hello(string name);Since this operation isn’t marked “IsOneWay=true”, it requires a request-reply channel. If you have a channel stack that only offers IRequestChannel, then Service Channel will use that shape directly. If your stack doesn’t offer IRequestChannel, but can create IDuplexSessionChannel, then ServiceModel will layer IRequestChannel on top of IDuplexSessionChannel (similar to how HTTP request reply is layered on top of a TCP connection).
With all this adaptation going on, how can you figure out what your stack will look like from a shape perspective? It’s not easy, but fortunately most users don’t need to worry about these details, they can simply trust that ServiceModel is creating a stack compatible with their endpoint. To decipher the magic, you need to understand what shapes each layer can offer, and under which conditions. For transports, it’s relatively straightforward, as they offer up fairly constant shapes (though they do occasionally vary based on configuration parameters). For layered channels you need to understand the mapping between what the layer beneath offers up, and how your layered channel can build upon those choices. That’s a topic for another time. For now, here are the choices for the transports:
The most common mode for Http is IRequestChannel/IReplyChannel. In order to support 2-way sessions, we also define a one-way mapping for Http. You can request IOutputChannel/IInputChannel from our Http Transport. In one-way mode, we will return a “202 Accepted” response with an empty body immediately on receipt of the Http request. We send this response before we dispatch the received message so that we can emulate datagram to the best of our capabilities given the inherent request-response nature of Http. When using WsDualHttpBinding you will see this behavior.
UPDATE (5/23/06, 9:22AM): In the latest V1 bits we’ve gotten crisper about our channel shapes. As Http is not natively one-way, it no longer supports IOutputChannel/IInputChannel. Rather, this “one-way over request-reply” functionality is provided by a layered binding element called OneWayBindingElement. Details of how this mapping works are outlined here.
TCP and Named Pipes have the same capabilities and support two patterns: IRequestChannel/IReplyChannel, and IDuplexSessionChannel. IDuplexSessionChannel is the natural shape of a “connection” (socket/pipe) and is the shape we return by default. An IDuplexSessionChannel maps 1-1 to a connection. Fortunately IDuplexSessionChannel also offers the most flexibility to the layers above it. You can build any other pattern (IOuputChannel/IInputChannel, IRequestChannel/IReplyChannel, IOutputSessionChannel/IInputSessionChannel, and IRequestSessionChannel/IReplySessionChannel) on top of IDuplexSessionChannel. The one pragmatic restriction of IDuplexSessionChannel is that it does not support Message Streaming. If you have streaming enabled on your binding (TransferMode != TransferMode.Buffered), then we use the IRequestChannel/IReplyChannel shape. In streaming mode, we need to use connections in more of an HTTP-like manner. A connection is exclusively checked out for the lifetime of a request-reply pair, and returned to a connection pool when the request-reply pair has completed.
Msmq not only supports IOutputChannel/IInputChannel, but they also support one-way session (IOutputSessionChannel/IInputSessionChannel) through a method they call “session-gram”. The way it works is that the Msmq Transport buffers all messages being sent on a sessionful channel, and when the session is closed they pass the entire session in a single Msmq message. This demarkated message is then received by the other queue and parsed into multiple messages.
As you might expect, when in “integration mode”, Msmq Transport offers up IOutputChannel/IInputChannel only.
It only took 7 months, but I have finally succeeded in my page rank quest. MSN Search caught on to my site relevance a few months ago as the top hit for “Kenny Wolf”, but when I had last checked Google I was on page 7 (both Lauren and my Mom were higher ranked matches). I thought they might have something against Microsoft employees 🙂
Then last night I saw myself at the top of the list:
At long last it looks like Washington State is getting on the no-smoking bandwagon. I-901 (Clean Indoor Air) was put to a vote, and with 94% of counties reporting, the current results have it passing by a wide margin (>63% in favor). Looks like I won’t need a special “bar jacket” anymore! 🙂
For those following along at home, the Secretary of State here has a great site for all election-related information.