|
|
Browse by Tags
All Tags » Answers » TCP/IP (RSS)
-
How do I detect when the other side of a TCP connection has gone away? Does TCP keep-alive take care of this for me? Although we take it for granted that change can be quickly detected for closely connected components, it turns out to be surprisingly difficult to detect change when two machines are isolated by more than a simple wire. Even a really big change to the system, like one of the machines disappearing, is hard to spot. Detecting that the other side has disappeared is a common request because, on a server, knowing that the client has dropped the connection allows you to clean up resources much faster. The TCP transport sometimes gives you quick notifications by aborting the session that the connection has been dropped. However, there's no guarantee that the transport will be able to detect that the other side has gone away. That's because notification of a TCP connection reset has to travel just like any other piece of data and can be lost or redirected along the way, if it was sent at all. The only sure thing is that the next time you attempt an IO operation, you'll find out if the channel was still good or not. If you're unhappy waiting for the next IO operation, then you can make IO operations happen faster. The basic concept is to have a cheap IO operation that does nothing but bounce between the two parties. This is sometimes called a heartbeat and is exactly what takes place when you talk about TCP keep-alive. However, the standard keep-alive interval for TCP is 120 minutes, which is probably worse than your current latency for detecting change. By default, a service gets bored waiting after about 10 minutes and gives up. The chance of a keep-alive happening between the time that a client disconnects and the service notices it is pretty small. If you want something faster but don't want to change the timeouts, then you can take the basic concept into your own hands. One approach is to create a keep-alive method on your service contract that does nothing but let you trigger IO operations at a frequency you desire. Another approach is if you control both ends and don't want to change your service contract, then you can do the same thing in a protocol channel and swallow those messages so that the service never has to see them. Next time: Collections without CollectionDataContract Read More...
|
-
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...
|
-
What is the lifetime of a TCP session? The lifetime of the session object from a TCP transport channel lasts exactly as long as you own the underlying TCP connection. Once you give up ownership of the TCP connection, either by saying that you're done with it or by having it fault, the lifetime of the session is over. Closing the channel is a way of saying that you're done with the TCP connection. The TCP socket connection may still be usable and go back into a connection pool to be circulated to someone else. Having the TCP socket connection fail is one way to cause the TCP channel to fault. This definition of lifetime means that there's no way to recover a TCP session once it has been closed or faulted. If you need to have a recoverable session, then you need to need layer a new session on top of the TCP session, such as with reliable messaging. Layering a new session on top allows multiple TCP sessions to be created and destroyed without affecting the session that is visible to the user. Next time: Ownership of HTTP Connections Read More...
|
-
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...
|
-
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...
|
-
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...
|
|
|
|