Monday, April 27, 2009

How does WCF implement per-session service?

In order to correlate all messages from a particular client to a particular instance, WCF needs to be able to identify the client. One way of doing that is to rely on a transport-level session; that is, a continuous connection at the transport level, such as the one maintained by the TCP and IPC protocols. As a result, when using the NetTcpBinding or the NetNamedPipeBinding, WCF associates that connection with the client. The situation is more complex when it comes to the connectionless nature of the HTTP protocol. Conceptually, each message over HTTP reaches the services on a new connection. Consequently, you cannot maintain a transport-level session over the BasicHttpBinding. The WS binding, on the other hand, is capable of emulating a transport-level session by including a logical session ID in the message headers that uniquely identifies the client. In fact, the WSHttpBinding will emulate a transport session whenever security or reliable messaging is enabled.

Because the service instance remains in memory throughout the session, it can maintain state in memory, and the programming model is very much like that of the classic client/server. Consequently, it also suffers from the same scalability and transaction issues as the classic client/server model. A service configured for private sessions cannot typically support more than a few dozen (or perhaps up to a hundred or two) outstanding clients due to the cost associated with each such dedicated service instance.


Saturday, April 25, 2009

Compare transport reliability and message reliability

WCF and other service-oriented technologies make a distinction between transport reliability and message reliability. Transport reliability (such as that offered by TCP/IP) offers point-to-point guaranteed delivery at the network packet level, and also guarantees in-order delivery of the packets. Transport reliability is not resilient to dropped network connections and a variety of other communication problems.

Message reliability, as the name implies, deals with reliability at the message level, independent of how many packets are required to deliver the message. Message reliability provides for end-to-end guaranteed delivery and order of messages, regardless of how many intermediaries are involved and how many network hops are required to deliver the message from the client to the service. Message reliability is based on an industry standard for reliable message-based communication that maintains a session at the transport level and supports retries in case of transport failures such as dropping a wireless connection. It automatically deals with congestion, message buffering, and flow control and can adjust the flow of messages accordingly. Message reliability also deals with connection management, verifying connections and cleaning them up when they are no longer needed.

Message reliability does not guarantee message delivery. All it provides is a guarantee that if the message does not reach its destination, the sender will know about it.

"Programming WCF Services, 2nd Edition"

Thursday, April 23, 2009

Why not use IP affinity and in-process session for V2 portal?

A friend proposed using sql server session instead of in-process session for V2 portal. My reason of using in-process session is that I thought IP affinity can resolve web farm issue and in-process session is simpler and faster than SQL server session. After further investigation, I found IP affinity cannot address web farm issue for V2 portal.

The types of IP affinity are described in <>:

“Single— In this mode, requests from new IP addresses are load balanced normally. From then on, the same server handles all requests from a given IP address. If servers are maintaining state information locally, this is a good setting for an intranet. However, Internet clients might seem to be coming from multiple IP addresses because of their service providers' network address translations, so this affinity mode won't work with the Internet.

Class C— In this mode, each range of 253 IP addresses in a Class C range is handled by a single cluster member. This mode largely defeats load balancing (because once a range of IP addresses is associated with a node, it won't ever be load balanced to another node), but it ensures that Internet users will always connect to the server that's maintaining their state information locally.

As you can see, Single mode works intranet but not internet. Therefore, Single mode may work for V1 portal (which uses windows authentication and is deployed in extranet) but not for V2 portal (which uses WLID and is deployed in data center). Class C mode is not really a real load balancing.

Thus, V2 portal has no other choice than using SQL server session.

Risk/Disadvantage of using SQL server session:
It is safe to assume that out-of-process session is 15-30% slower, depending upon variables such as network speed and the size of the object or objects being serialized. (

What to do to switch to SQL server session:
1. Make the classes used in SessionObject serializable.
2. update the V2 portal installer to support Server sql session.

This is the command to create session related tables in PortalDB instead of the default TempDB.

aspnet_regsql.exe -S MachineName\SqlInstanceName –E -d PortalDB -ssadd -sstype c