Browse by Tags

• Announcements
• Answers
• Hosting
• Indigo
• Networking
• Service Architecture
• Transports

• More about Client IP Addresses

  Back in May I talked about the problem of getting client IP addresses , which you don't have any good way to solve today in WCF. There were a lot of strong comments on that post that this was a feature that people really needed. As it turns out, this was a feature that we wanted to get into Orcas but couldn't get approval. I took the same questions to TechEd to see what people would say. A lot of customers there really wanted this feature as well. The good news is that we were able to use all of that feedback to get the feature approved and into the product. When using the TCP and HTTP transports, you'll be able to get a message property off of each message that tells you the IP address and port number of the machine that sent the message. The bad news is that because this was a feature that we did very late, it wasn't done in time to appear in the beta releases. We've actually had this done for a few weeks but people continue to ask for the feature because we've had no way to tell you about it. Rather than let that continue, we decided to let you know that this was one of the things coming in the final release that you haven't had an opportunity to see yet. Phil Henning is the developer that worked to get this done and he's really wanted to talk about it in the meantime so for those of you that are interested, I'm going to let Phil give you more details about how the message property is used. You should expect to see a post on his blog later today. Read More... Posted Monday, September 10, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Announcements, TCP/IP, HTTP

• 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

• Format for Configuring HTTP and TCP Activation

  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... Posted Wednesday, November 29, 2006 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Transports, TCP/IP, HTTP, Answers

• Keeping Connections Open in IIS

  My web service needs to periodically broadcast messages to clients. The service is an Internet-facing application hosted inside of IIS. What’s the best way to do this? The big limitation in this scenario is that your clients might be behind a firewall and non-addressable. There are basically two architecture camps for broadcasting messages to clients over the Internet. The push architecture camp has the clients maintain a continuous connection to the server and pushes data out at each update. The pull architecture camp has the clients periodically poll the server to see if there’s any new data. Both of these architectures are widely used and they trade latency versus resources off of each other. There are a few other architectures that work locally as well but aren’t as useful over the Internet, such as multicasting and callbacks. I’m just going to pick one of these and talk about using a push architecture. The basic way to build a push architecture is to have clients connect to the server and then the server holds the connection open indefinitely to send messages. If your service is hosted in IIS version 6 or below, then you don’t have a lot of choice about the network protocol. Pushing data from the server to client is difficult with HTTP because the protocol is built on top of the request-reply model. A typical way of using HTTP to push is to make an empty request and send back a response using the chunked transfer encoding. Chunked transfers allow an HTTP server to send the response in pieces without having to specify the total length of the response up front. Normally, the client knows the message is done when the connection is closed or the pre-announced content length is reached. Neither of those options work in this case. Instead, the server needs to define some framing protocol so that the client can tell when the individual messages are done. The easiest way to get chunked HTTP transfers in WCF is to use the HTTP transport with streaming enabled. If your service is hosted in IIS 7 (the Vista/Longhorn version of IIS), then you are able to pick other network protocols for your service, such as TCP. TCP is inherently duplex so it works across the Internet for server-initiated transfer of messages without having to connect back through a firewall. Since TCP is duplex, you can write a duplex contract that gives you a very nice programming model for sending the broadcasts. This is a lot less work on your part than the equivalent setup needed with HTTP. Read More... Posted Friday, October 20, 2006 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Networking, Indigo, TCP/IP, HTTP, Answers, Service Architecture