|
|
Browse by Tags
All Tags » Bindings » Transports (RSS)
-
The basis of a channel stack is that there is a series of objects that share a common interface for communication. This leaves message encoders with something of a problem as the primitive operations for encoding and decoding messages are different than the primitive operations for sending and receiving messages. Message encoders avoid this problem by being contained within a channel rather than acting as a peer in the channel stack. However, this is different than the model used for bindings, which make the message encoding binding element a peer of the other channel binding elements. To make things harder, bindings use a "no lookahead" construction process where constructing an object cannot speculate about future construction by looking into the unprocessed information in the binding. That results in a subtle dance between a message encoder and a channel that wants to use a message encoder. During the construction process, a binding gives you only a context for storing computed information and the ability to initiate the next phase of the construction process. When we go to build a message encoder, it's not possible to actually build anything because the channel that will hold the message encoder doesn't exist yet. The message encoder doesn't know how or why it is going to be used. Instead, what a message encoding binding element does to build is add itself to the BindingParameters in the context. The message encoding binding element then initiates the next phase of the construction process. At some point in the future, a channel may look at the context to see if it contains a previously saved binding element, which can now be built. The delay in instantiation is what allows channels to have a different order for physical containment than the logical order of the binding elements. Next time: Quotas for Copying Messages Read More...
|
-
You may have noticed that an HTTP binding is configured with an HttpClientCredentialType whereas an HTTP binding element is configured with an AuthenticationScheme. How are these two settings related? If you want to switch between a custom binding and a standard binding for HTTP, then you need to know how to do the translation. Here's how client credentials map to authentication schemes: HttpClientCredentialType.None becomes AuthenticationSchemes.Anonymous HttpClientCredentialType.Certificate also becomes AuthenticationSchemes.Anonymous. Certificates are used with HTTPS rather than as authentication credentials on top of HTTP. This will be caught in validation if you try to use certificates with the TransportCredentialOnly security mode. HttpClientCredentialType.Basic becomes AuthenticationSchemes.Basic HttpClientCredentialType.Digest becomes AuthenticationSchemes.Digest HttpClientCredentialType.Ntlm becomes AuthenticationSchemes.Ntlm HttpClientCredentialType.Windows becomes AuthenticationSchemes.Negotiate Translation works the same way with proxy credentials and the proxy authentication scheme except that proxies don't have to worry about the issue with certificates. Next time: Get a Real XML Parser Read More...
|
-
This is more of a reference than anything else. People have asked me what interfaces do something when used with GetProperty on a binding element. Of course, a custom implementation can do whatever it wishes in its GetProperty, so I can only tell you what the standard implementations have done. Also, GetProperty is chained from one place to another. For example, if a property is not found on a channel binding element, it is likely to go off looking at lower binding elements in the channel stack, the message encoder, and so on. What's listed here is just what is specifically handled in a given implementation. I've split this list into "transports" and "everything else". The base class for transport responds to three types. ChannelProtectionRequirements (this just give the default values) MessageVersion (SOAP 1.2, WS-Addressing 1.0) XmlDictionaryQuotas (this just gives the default values) The HTTP and HTTPS transports respond to three additional types. Also, these transports automatically check against the properties of a text message encoder if you didn't specify any encoder at all. None of the other transports do this for you. ISecurityCapabilities IBindingDeliveryCapabilities TransferMode The TCP and Named Pipes transports respond to only two additional types. IBindingDeliveryCapabilities TransferMode The Peer transport responds to three additional types. IBindingMulticastCapabilities ISecurityCapabilities IBindingDeliveryCapabilities The MSMQ transports respond to three additional types. The last one only occurs for the Integration mode of MSMQ. ISecurityCapabilities IBindingDeliveryCapabilities MessageVersion (always set to None for Integration mode) Next time: Interfaces for GetProperty, Part 2 Read More...
|
-
This is just a style convention that helps you avoid doing some thinking while writing custom channel classes. During the channel construction process, there's a flow of information from the binding (design time), through the channel factory and listener, and down to the channel (run time). The channel needs to know about the configuration changes that the user has made in setting up the binding. As we've seen before, there's some difficulty with storing this information outside the channel , so we can't rely on referencing the information indirectly through another object after creation. Here's the convention that we've sort of settled on in most of our channels. When creating the channel factory or listener (jointly referred to as the channel manager), the constructor takes two arguments. The constructor gets the this instance of the binding element that is building the channel manager. Inside the constructor, the configuration settings of the binding element are copied to private fields of the channel manager. The channel manager doesn't hold on to the binding element after initialization is complete. The constructor gets the binding context instance that the binding element was passed. The binding context instance allows the channel manager to fish out the inner channel manager and access binding parameters. When creating the channel, the constructor takes as many arguments as it needs to pass all of the private data that was being stored in the channel manager. It can be helpful to group some of these arguments using a specializeed interface if you need to pass around the same information to a lot of different places. The channel manager does not give the this instance to the channel normally. An exception is if you're using the ChannelBase class for your channel, which requires an instance of ChannelManagerBase. In that case, the channel manager gives its this instance to the channel solely for that purpose. The channel constructor takes that instance as a ChannelManagerBase rather than using a specialized type. Next time: Mixed Mode Addressing Read More...
|
-
I drew this picture for myself while working on the guidelines for implementing GetProperty . I figured that other people might find it useful as well. One of the guidelines is that queryable properties on design time objects should flow to the corresponding run time objects. The black boxes show the classes that support GetProperty and the black arcs show the anticipated flow of properties. The red boxes show the classes that don't support GetProperty today but might make sense to have support in the future. Read More...
|
-
This post is just some quick thinking about guidelines for implementing the GetProperty method. These guidelines are still in development so think of this as a draft rather than real guidance at this time. Background: We provide an extensibility point called GetProperty on many of the components you can build using the channel model. The exact list of components that support GetProperty are bindings, binding elements, channel factories, channel listeners, channels, and message encoders. GetProperty allows someone to execute a strongly-typed query against your component to inspect its configuration settings. GetProperty takes a type parameter T and either returns some instance of T or returns default(T) to indicate that the type is unknown. DO expose configurable settings for your component using GetProperty. GetProperty should be used in preference to ad-hoc methods for searching through a stack of components. DO NOT require the use of GetProperty to access mandatory or intrinsic configuration settings. The types supported by GetProperty are not discoverable and any setting that your component considers mandatory should be accessible through the object model. GetProperty can be used as an alternative way of accessing the same value. DO support in your runtime objects every property that was available on your design time objects. If a channel factory exposes a setting, then every channel produced by that factory should expose a corresponsing setting that tells you what the value was when the channel was created. DO create specialized interfaces that capture each class of information that you want people to query on. Specialized interfaces promote the reuse of a particular type for semantically identical settings. DO reuse existing interfaces if your information has exactly the same semantics as the previous use. Conversely, if your settings don't have the same semantics, don't reuse a type just because it's more convenient to do so. DO NOT key properties off of commonly used types with a generic meaning. Types that appear frequently, such as IDisposable, will not have consistent semantics for all of their potential uses. DO NOT key properties off of value or enumerated types. We enforce this by placing a restriction on the generic type parameter. DO delegate down to inner channels, channel factories, and channel listeners when they exist and your component does not know about the requested type. We have a pipeline model that supports the composition of many Read More...
|
-
Yesterday's post covered most of the big new features that were added in the latest release . Today I'll go through the rest of the new features that are smaller in scope although no less exciting. #1: When the channel stack is being built from binding elements, some binding elements want to know what elements are underneath of them so that they can properly configure themselves. Previously, there was no way for custom binding elements to get at this information. We made the RemainingBindingElements property on the binding context public so that your binding elements can work exactly the same as ours. #2: Transport stream upgrades frequently operate on a point-to-point basis, but the API for providing stream upgrades previously only gave the upgrade provider the final address of the connection. We've changed the interface for StreamUpgradeProvider so that upgrades can see both the endpoint address and the via address of the next hop. #3: It's now possible to disable the use of HTTP keep alive. We added a KeepAliveEnabled option to HttpTransportBindingElement with the default set to enabled, which was the old behavior. This option is only available on the binding element so you'll need to use a custom binding if you need to change this setting. #4: There's now a quota setting for how long a connection can take to authenticate. A client needs to send a few hundred bytes of data before the server has enough information to perform authentication. Previously, the client had the entire receive timeout in which to send this data. The header is often much smaller than a normal sized message and clients are anonymous until this information is processed. The ChannelInitializationTimeout on the binding element limits the amount of time a malicious client can tie up one of the connections for your server. We also changed a few interfaces into abstract base classes although we didn’t add any new functionality to those classes at this time. The IRequestContext interface is now the RequestContext class and the IStreamUpgradeBindingElement interface is now the StreamUpgradeBindingElement class. I had a list of changes that I was hoping to get through during this week. However, the first two days ran a little bit long so there are still a few more items to cover. I'll run one more installment of this series on Monday and the next set of topics will start after the 4th of July holiday. Next time: Some Changes for Channels and Transports in the June CTP, Part 5 Read More...
|
|
|
|