Browse by Tags

• Answers
• HTTP
• Indigo

• Configuring TCP Activation from the Command Line

  Can I configure non-HTTP web service activation from the command line? Yes, and you don't need any special tools if you're already familiar with configuring IIS from the command line. I've already talked about how to configure a new web site or application for activation in a previous post. Modifying the configuration uses the same appcmd program that is installed as part of the IIS scripting tools. It's installed on my system as %windir%\system32\inetsrv\appcmd.exe. All modifications to the web site are going to start with appcmd set site sitename and all modifications to the application are going to start with appcmd set app appname . The sitename and appname are the long path name for the web site or application, such as "Default Web Site" or "Default Web Site/myapp". The list of protocols for activation is associated with the application. Enabling an application to be activated using TCP would look like appcmd set app "Default Web Site/myapp" /enabledProtocols:net.tcp . The protocol configuration is associated with the web site. Each protocol configuration is called a binding (not related to a WCF binding) and corresponds to a protocol scheme, IP address list, port, and host header. Not all protocol schemes are going to support all of those other things. Adding a new configuration for TCP would look like appcmd set site "Default Web Site" -+bindings.[protocol='net.tcp',bindingInformation='808:*'] . That same binding would be deleted by changing the plus to a minus, appcmd set site "Default Web Site" --bindings.[protocol='net.tcp',bindingInformation='808:*'] . Changing the IIS configuration requires administrator approval. If you don't have permission to access the configuration file, you'll get an error that looks like this: ERROR ( message:Configuration error Filename: \\?\C:\Windows\system32\inetsrv\config\applicationHost.config Line Number: 0 Description: Cannot read configuration file . ) Next time: Address Filters that Swallow GET Read More... Posted Wednesday, September 12, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, TCP/IP, Answers, Hosting

• Hosting on Machines with Multiple Addresses

  I have a machine with multiple network cards. How do I control which networks my service listens on? The answer to this question is going to be specific to the transport that you're using. I'll cover the HTTP and TCP transports that WCF ships with. Talking about addresses for the named pipe transport is less interesting because we don't allow remote connections with our named pipes! With custom transports, you're on your own and will have to contact the author. The TCP transport is very liberal with wildcarding addresses. When given a choice of multiple addresses for a machine, it will listen on all of them. To change this, you need to prevent the transport from having this choice. Here are the two things that you will need to do. First, make sure that the HostNameComparisonMode property for the transport is set to Exact. HostNameComparisonMode controls the address wildcard and the Exact option means that the hostname and port have to match exactly. Second, change the listening address of the service from a hostname to an explicit IP address. This guarantees that you'll get the specific network address that you want. Now, you've removed all choice from matching the address of the service, and you have a service that only listens on a single one of your multiple addresses. The HTTP transport is a little bit more flexible with wildcarding because it can leverage a feature built into the platform for HTTP. The HTTP.SYS driver allows you to define an IP Listen List that contains a particular set of IP addresses to listen on for HTTP connections. If you don't have a listen list configured, then by default the HTTP transport will be listening on all of the available network addresses, exactly like the TCP transport. The same technique for listening on just a single address with HostNameComparisonMode works for HTTP as it did for TCP. Finally, I thought it important to mention that just about every computer these days has multiple IP addresses- even if you don't have multiple network cards. You have a loopback IP address (127.0.0.1 for IPv4) that always corresponds to local connections and a real IP address from your network adapter. This means that you have everything you need to craft a "local machine"-only service even when not using named pipes. The guarantee when doing this is a little bit weaker than the one we make for named pipes though. We block remote users that are going through a local intermediary from named pipes by filtering on the origin of the account Read More... Posted Monday, January 08, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, TCP/IP, HTTP, Answers, Hosting