|
|
Browse by Tags
All Tags » Answers » Transports (RSS)
-
I need to make many simultaneous HTTP calls to the same service from my client application. How do I increase the limit on the number of HTTP connections? This setting isn't available on any of the bindings or binding elements but the default limit can be set through the DefaultConnectionLimit property on System.Net.ServicePointManager. This will change the limit for every server you want to connect to. Alternatively, you can control the connection limit very granularly through configuration. < system.net > < connectionManagement > < add address ="..." maxconnection ="2" /> </ connectionManagement > </ system.net > The address can be for a particular HTTP address or for a plain machine name. Use the wildcard character * for the address to set the default connection limit through configuration. If a request can match against more than one of the configuration entries, then the most specific entry is the one that will be used. Next time: Mapping Credentials to Authentication Schemes Read More...
|
-
I've got a sessionful contract that I want to use with HTTP. How do I get the HTTP transport to produce a sessionful channel shape? The basic design principle of channels is that they produce whatever channel shape is their natural message exchange pattern. For HTTP, the natural message exchange pattern is request-reply. This means that if you want any other channel shape, then you need to apply a layered channel that changes the message exchange pattern. That is the approach regardless of whether you want to change the channel shape to one-way, duplex, or a sessionful channel. There are no built-in HTTP specific additions to create sessionful channels. We have a sample channel that demonstrates creating a session based on HTTP cookies . There are several general-purpose protocol channels that provide sessions, such as security and reliable messaging. However, this entire line of conversation tends to indicate a fundamental flaw in thinking. A session has the semantic meaning of correlating messages together according to some principle of relationship. Sessionful services use the relationship to treat the session of messages as a connected unit. The meaning of that session ought to be a more significant factor than whether some contract has been previously declared to know about sessions. If you are scrounging around to come up with any possible session to get a service working, then something is probably wrong. Next time: XML Support Read More...
|
-
Why doesn't anything happen when I try to add HTTP headers from a message encoder? The problem here is a basic issue of timing. Recall the interface contract that a message encoder has with its transport. The transport receives a message from the next channel up in the channel stack, does some processing on the message, and calls WriteMessage on the message encoder when it wants to write out the message body. The message encoder does not necessarily see all of the message content. Some message content, such as framing, is independent of the message encoding and directly handled by the transport. In fact, the message encoder may not be called at all if there is no content for it to write. HTTP headers are an example of content that is handled by the transport rather than the message encoder. The message encoding transforms the body of the message, but HTTP headers are always sent as text. In the call to WriteMessage, the message encoder does get a Message object, which has a handle to the HTTP headers. However, if you look at the format of a raw HTTP message, then you would see that the HTTP headers are completely written out before the message body is written out. When streaming an HTTP message, the headers may even be transmitted before the message body is written out. Therefore, you should guess that it's unlikely that the message encoder can do anything with the HTTP header collection because the HTTP headers may already have been transmitted. If you want to change the HTTP headers, then you should make sure that all of the changes are made before the transport is given the message. Next time: WCF Case Studies 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...
|
-
Can I write a point-to-point router service by setting the Via property for outgoing messages? Like most things, this is going to depend on the specific behavior of the transport channel you're using, but in general the answer is no. The transport channel owns the Via property and it will stomp over whatever you write into the message headers. You do have one opportunity to set the channel's Via, which is during the creation of the channel from the channel factory. After that, the matter is out of your hands. This would imply creating a channel per message or keeping a pool of these channels around to farm out messages if you keep using the same destinations over and over. There is a different story if what you want to route to is the ultimate receiver To address instead of the Via address. You can set the To address on a per-message basis, assuming that the transport channel has implemented the ManualAddressing setting . Next time: Enabling Kerberos in IIS Read More...
|
-
I occasionally see people asking how they can fake the security capabilities of a binding. These questions often start off with "I'm getting an error message that a message's required protection level is not being met". Now, I'm not precisely sure why you'd want to fake the security capabilities in this case. After all, the application developer is in charge of both specifying the protection requirements of the messages and choosing what channels to use. If they're getting this error message, then it more than likely means that this helpful check has detected a problem somewhere in their design. There are a few rare reasons why you'd want to fake this, but they mainly involve transmitting over specially secured networks. However, it turns out that faking security capabilities is exactly the same as legitimately specifying the capabilities of a custom channel so I might as well explain that! Security capabilities are found by querying the channel stack with GetProperty for an instance of ISecurityCapabilities. This call should be supported on the binding element of channels that implement message or transport security. Transport channels should respond with something, even if it is to say that they don't support any kind of security. Everyone else can just delegate the call to their inner channel (which is typically what you do by default for any type you don't know about). public interface ISecurityCapabilities { ProtectionLevel SupportedRequestProtectionLevel { get; } ProtectionLevel SupportedResponseProtectionLevel { get; } bool SupportsClientAuthentication { get; } bool SupportsClientWindowsIdentity { get; } bool SupportsServerAuthentication { get; } } The fields here should be self-explanatory, you either support a particular feature or you don't, but let's look at examples from some of the existing channels. HTTP doesn't support any protection on requests and responses, neither encryption nor signing. HTTP supports client authentication when in any security mode but Anonymous. It only supports server authentication when using Negotiate security. Windows identities are supported whenever client authentication is. On the other hand, HTTPS provides both encryption and signing for both requests and responses. HTTPS always does server authentication. It supports client authentication and Windows identities whenever HTTP would plus whenever client certificates are turned on. You can quickly get a sense of the differences between HTTP and HTTPS by looking at Read More...
|
-
How can a client application control the To address of an outgoing message? I don't want to create a new proxy for every connection. This is one of those topics that I could have sworn that I wrote about but can't find any evidence of it online. Actually, I was going through some papers the other day and found notes for five or six topics that got sketched out but never published. I'm guessing that that's what happened to the advice on manual addressing. In light of this discovery, today I'll focus solely on manual addressing from a service perspective and leave the channel perspective on manual addressing for another time. Manual addressing controls the stamping of addressing headers on outgoing messages. Normally, the transport just overwrites the message headers with whatever addressing information it's been configured with. No amount of fiddling at the service level will change that behavior because any existing addressing headers get obliterated when going through the transport. However, some transports, such as HTTP, have a setting on the binding element called ManualAddressing that turns off this automatic stamping behavior. Other transports, such as TCP, don't offer this option because it's not possible to redirect an existing TCP connection on a per-message basis. This isn't a problem for HTTP because every HTTP request can have its own connection if desired. Support for manual addressing of messages is purely a transport-specific feature. The answer to the question therefore comes in three parts. First, make sure that the transport that you're using supports some form of manual addressing. If not, then you're out of luck in terms of sending messages to different destinations without creating some new object on a per-destination basis. Second, turn on that manual addressing option to prevent the automatic application of addressing headers during message sends. Third, use whatever method you want to apply your own addressing headers to the outgoing message. If you're just making service calls on a proxy, then you'll want to use something like this: OperationContext.Current.OutgoingMessageHeaders.To = this .replyTo.Uri; If you're creating Message instances yourself, then you'll want to apply your addressing headers to the message header collection and so on. Next time: MSMQ: Net vs Integration Read More...
|
-
The HTTP transport and binding element have three settings for controlling the proxy behavior. public bool BypassProxyOnLocal { get; set; } public Uri ProxyAddress { get; set; } public bool UseDefaultWebProxy { get; set; } UseDefaultWebProxy controls whether manual proxy settings are used or whether the automatically-configured system proxy settings are used. ProxyAddress is how you manually specify the proxy. If you're using the automatically-configured proxy, then you can't also specify a manual proxy address. Finally, BypassProxyOnLocal allows you to control whether the proxy is used for destination addresses that are on your local network. Requests to any loopback adapter address or the special host name localhost are always bypassed. Even if you set BypassProxyOnLocal to false, requests to these addresses will still not go through the proxy. Unfortunately, overriding this behavior would require writing a custom instance of IWebProxy and attaching that proxy to the underlying web requests that are being made. It's more common to hit this problem during development when you're testing on a machine that doesn't have the same networking setup that the real server will have. One workaround is to install a virtual network adapter that performs loopback in software. This allows you to send requests to an address that is not classified as a loopback without having to add new hardware to your system. Next time: Registration of Base Addesses Read More...
|
-
IIS uses some inscrutable strings to configure the activatable bindings of a web site. Here's the minimum you need to interpret a binding and get started working with activation. Activation is controlled by the activationHost.config file. In the list of web sites, each site has a binding section that contains the list of supported protocols. < site name ="Default Web Site" id ="1" > < bindings > < binding protocol ="HTTP" bindingInformation ="*:80:" /> < binding protocol ="net.tcp" bindingInformation ="808:*" /> </ bindings > </ site > The format for the HTTP binding information comes from IIS. It has three parts separated by colons. The three parts are List of IP addresses to listen on (or a wildcard symbol) Port number List of host headers (or blank) The format for TCP was picked to be as similar as possible to what already existed for HTTP. We have two parts to configure, again separated by colons. There is no equivalent for the list of addresses. The two parts are Port number Host name comparison mode (blank or a wildcard symbol) Next time: Proxy Bypassing Behavior Read More...
|
-
This time it's two questions that have the same answer. What contract does the message encoder have for producing a message from ReadMessage? What should the transport do if the message encoder doesn't produce a message from the buffer you give it? The contract of the message encoder is that it will always either throw an exception or produce exactly one message each time ReadMessage is called. This means that a properly-written message encoder will never fail to produce a message without throwing an exception out of ReadMessage for the transport to handle. As you might recall, the contract that the transport must abide by is that operations should only throw exceptions that are subtypes of CommunicationException, TimeoutException, or some fatal exception type (such as OutOfMemoryException). The transport should catch all exception types that it knows the message encoder will produce, such as XmlException, and wrap those in some instance of CommunicationException. A good choice would be ProtocolException. However, the transport should not just eat all types of exceptions. It's best to let a stray exception through unless it is a specific, known type because you run the risk of trapping a fatal exception. What happens to the message after the transport gets it back from the message encoder is no longer constrained by the contract of the message encoder. Next time: How to Configure MaxItemsInObjectGraph Read More...
|
-
How do I configure my service to listen on all of the host names for my machine? How do I configure my service to only listen on one particular host name? I sometimes see these funny + and * characters in URLs when using WCF. What do these characters mean? All three of these questions are related to the feature we refer to as HostNameComparisonMode. WCF matches addresses to listening services by comparing the address you specified to several tables of address prefix paths. A prefix path claims a particular address and can also optionally claim the entire namespace of addresses that start with that prefix. Of course, someone could then claim a longer (and therefore more specific) address inside of the namespace to provide a more suitable match. The + and * characters are wildcard symbols that match against any host name for the machine. There's no special symbol for exactly matching the name, that's just done by writing out the name itself. I was going to follow that by explaining how HostNameComparisonMode and prefix matching work in detail, but I found out that Kenny Wolf has already explained comparison and matching . Next time: Keeping Connections Open in IIS Read More...
|
|
|
|