Browse by Tags

• Channels
• Documentation
• Indigo

• Some Changes for Channels and Transports in the June CTP, Part 3

  Today's look at recent changes covers two cool new features. #1: Better support out-of-the-box for building applications in the POX/REST style. Back in March, I talked about the POX support we added for the February CTP and a bug we found in our implementation of HttpMappingMode . There were two problems in that release. The first problem was the unfortunate functional bug that made it far too easy to shoot yourself in the foot when building an application. The second problem was that the multi-state mapping mode setting was a confusing and clunky way of enabling this architectural style. It was better than having to install an unsupported POX encoder sample on your production machine, but it still was not good. In June, you can now see our new approach to solving this problem. Support for POX is built into the normal text encoder. Fundamentally, using the POX style means that you want our messaging layer to not add the SOAP and addressing goop that it normally sticks into every outgoing message for you and not require that goop on every incoming message. We already had knobs for controlling how to format the goop in the encoder. Our solution was to add a "none of the above" option to these knobs. Setting MessageVersion to None means taking the "none of the above" option for every part of the message, or equivalently, it means "no goop please". #2: Better support for using packet routers. The two major kinds of routers are circuit-based routers and packet-based routers. A circuit-based router affinitizes the incoming and outgoing connections. This makes the router almost transparent to the way we think about connectivity (the router is still not transparent to the way we think about message passing though, for instance transport security is point-to-point). A packet-based router treats everything like a datagram and doesn't care about connections. Packet routers work well with fire-and-forget messaging. Transports that are inherently request-reply, such as HTTP, don't work so well with packet routers when they need to send back failure notifications. When an HTTP message arrives at a packet router, the router needs to make the reply immediately. Once the message moves on to the next hop, the router forgets everything about the reply connection so there's only one opportunity to send the reply message. Typically, the router just sends back an acknowledgment that the packet was received. However, if an error occurs several hops later, there's no way to route Read More... Posted Thursday, June 29, 2006 5:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Messages and Encodings, Transports, Channels

• Framing Size Limits for the Tcp and Named Pipe Transports

  I've talked about the framing that goes on in the network stack before, but today's topic is a case where the framing actually affects what your application can do. Inside the WCF transport, essentially the uppermost level of the WCF network stack that actually has a byte stream, we need to make a decision about how that stream of bytes will get pushed onto the wire. A WCF message has an almost unlimited size . You can of course constrain the size of messages that you’ll deign to receive, but in theory it's possible to create really, really big messages and there might be someone actually willing to receive a message that big. Network messages almost never have an unlimited size. Some network transports (the layer below WCF transports) cap out at hundreds of bytes , while others cap out at millions of bytes (queues, but I haven't talked about those yet), but nearly all have a cap that is less than the quadrillions or quintillions of bytes you can stuff into a WCF message. How is it possible to actually send a WCF message over a size-constrained network transport? The solution is message framing. Surrounding each message is contextual information that allows the receiver to reassemble fragments into the original WCF message. Each transport is responsible for splitting the byte stream, applying its own framing format, and performing the reassembly. At the beginning of the message are two pieces that could conceivably be quite large, the via for message delivery and the content type of the message. Now, these pieces are constrained by your maximum message size, but you have to know where the message is going before you can do things like perform user authentication. This is a sticky point because while you might be ok with authorized users sending you millions of bytes, you probably don't want unauthorized users to do the same. This was a somewhat long digression to motivate a problem you might encounter with our TCP and named pipe transports. The framing format for these transports specifies that the receiver may, if they want to, cap the maximum size of the message via and content type. That's the Via property on your IOutputChannel and the ContentType property on your MessageEncoder . We do in fact want to do this. There are even specific faults to send back in the event that the limits are reached. What you probably want to know though is: what are those limits? 2048 bytes for the message via and 256 bytes for the content type. Next time: Mapping Channels Read More... Posted Tuesday, June 20, 2006 5:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Messages and Encodings, Transports

• Choosing a Transport

  This is the last planned article in a documentation series covering various aspects of Windows Communication Foundation transports. Today's topic covers how to choose a transport and associated encoder. Choosing a Transport The Windows Communication Foundation (WCF) programming model separates the behavior of endpoint operations from the transport mechanism that connects two endpoints. This gives you flexibility when deciding how your services should be exposed to the network. Transports and message encoders are pieces of WCF that sit below a service to provide connectivity. This document discusses some of the characteristics you need to evaluate when choosing a transport and message encoding. In scenarios where you must connect to a preexisting client or server, you may not have a choice about using a particular transport and message encoding. However, WCF services can be made accessible through multiple endpoints, each with a different transport or message encoding. When a single selection does not cover the entire intended audience for your service, you should consider exposing your service over multiple endpoints. Client applications can then choose the endpoint that is most favorable for them. Using multiple endpoints allows you to combine the advantages of different transports and message encoders. Transports and Message Encoders In WCF, the transfer of data across a network requires the joint cooperation of a transport and message encoder. A message encoder converts a System.ServiceModel.Channels.Message to a serialized form. This document covers the Text, Binary, and MTOM message encoders that are included in WCF. The text message encoder supports both a plain XML encoding as well as SOAP encodings. The plain XML encoding mode of the text message encoder is called the POX encoder to distinguish it from the text-based SOAP encoding. A transport sends the serialized form of the message to another application. This document covers the HTTP, TCP, and named pipe transports that are included in WCF. WCF provides several standard bindings that combine a transport, message encoder, and other options. For instance, the BasicHttpBinding binding combines the HTTP transport with a text message encoder. Similarly, the NetTcpBinding binding combines the TCP transports with a binary message encoder. You are not limited to choosing a preset combination given by a standard binding. Decision Points for Choosing a Transport The following table describes several decision Read More... Posted Wednesday, May 24, 2006 5:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Messages and Encodings, Transports, Documentation