|
|
Browse by Tags
All Tags » Reliable Messag... » Indigo (RSS)
-
You may have noticed that bindings use two different classes for configuring reliability: ReliableSession and OptionalReliableSession. The only difference between the two is that OptionalReliableSession has an Enabled property that allows the reliable session to be turned off. If you only have a ReliableSession to work with, then there is no way for it to be disabled. The only standard binding that uses ReliableSession is WSDualHttpBinding. All of the other standard bindings that support reliability, such as NetTcpBinding and WSHttpBinding, use OptionalReliableSession. Why is WSDualHttpBinding the only one that has to be reliable? The reason for this is that WSDualHttpBinding has to coordinate together two different connections. The stack of binding elements for WSDualHttpBinding looks like this: TransactionFlowBindingElement ReliableSessionBindingElement SecurityBindingElement (optional) CompositeDuplexBindingElement OneWayBindingElement TextMessageEncodingBindingElement (or MtomMessageEncodingBindingElement) HttpTransportBindingElement Composite duplex splits the binding into separate input and output connections, and relies on a higher-level component to correlate the two. There are many ways to provide that correlation, one of which is a reliable session. Requiring that the reliable session be present matches the most common usage pattern and allows the other potential correlation mechanisms to be omitted without having to validate the resulting binding configuration. That's why WSDualHttpBinding requires a reliable session. If you have a different correlation mechanism that you want to use together with composite duplex, then you can build that with a custom binding. Next time: Context Channel Shapes Read More...
|
-
Why doesn't validation catch when the two sides of a reliable connection disagree about whether the session is ordered? It doesn't actually matter to the sender whether the session is supposed to be ordered, and so it doesn't actually matter whether the two sides agree. The sender has a direct and perfectly reliable view of the messages in the sequence as they're generated. In essence, the order of the messages is whatever order the sender chose to send them in. On the other hand, the receiver has an unreliable view of the message sequence. The purpose of a reliable messaging protocol is to reconstruct a reliable view from that unreliable view. Therefore, the receiver actually has a choice about whether the original sender order is important and should be reconstructed. This is different than saying that ordering is useless on the client. Client and server are ideas about the organization of a system; sender and receiver are particular roles in a protocol. A client could be both sending and receiving messages. Next time: Overriding Protection for IPSec Read More...
|
-
I'm using reliable messaging and getting an exception that the reliable session has faulted. It's the first exception that I see so I don't know why the session faulted. How do I know what went wrong? Here's the full error message: The underlying secure session has faulted before the reliable session fully completed. The reliable session was faulted. The reliable messaging channel threw an exception because the reliable session was broken. The reliable session was broken because the security session was broken. In this case, you know that the security session was broken without seeing any other exceptions being thrown. That means the security channel must have faulted without encountering an exceptional event, which triggered all of the other visible results. The easiest way to debug a situation like this is to start removing extraneous pieces. Try removing the reliable messaging channel and see if that allows whatever went wrong with the security session to bubble up. If things immediately fail at startup, then try removing both the reliable messaging and security channels. There may be something basic about your configuration that's incorrect and removing protocol layers will help you find that faster. Next time: Localhost Common Name Read More...
|
-
When you create a sessionful channel, that implies the existence of some correlation factor for all of the messages that are associated with the session. For example, the correlation factor for a TCP session is that all of the messages travel over the same TCP connection and the correlation factor for a WS-RM session is that all of the messages belong to the same reliable sequence. There is no way to identify what the correlation factor is at runtime but the channel provides an ISession object so that one correlation factor is distinguishable from another. This is done just by having a unique identifier associated with the session. Since the session and session identifier are part of the channel interface for a sessionful channel, it's possible to try to access the session as soon as the channel is created. However, there's no guarantee that the session information is valid if the channel is not open at the time. Here is how some of the standard client-side sessions behave if accessed after the channel is created but before the channel is opened. TCP session: A unique identifier is generated on the fly, this identifier will continue to be used after the channel is opened. Reliable session: The session identifier is empty, an identifier will be created when the channel is opened. Security session: Trying to access the identifier produces a runtime exception, an identifier will be created when the channel is opened. In short, you can't rely on any meaningful behavior for the session until you're ready to start sending data. Next time: Substituting for TryAccept Read More...
|
-
The results last time were in disagreement with the rule of thumb that turning on reliable messaging cuts your throughput roughly by half . One possible explanation for the disagreement is that the measurements were looking at the wrong thing. The measurement being used was efficiency: the ratio of the throughput with reliable messaging enabled to the throughput with reliable messaging disabled. For all but the smallest sizes of reliable sessions, reliable messaging over HTTP had an efficiency of at least 0.5. The largest size of reliable session had efficiency near 0.9. For the rule of thumb to be true, you'd expect to see most sizes of reliable sessions have efficiency near 0.5. HTTP has a datagram request-reply message exchange pattern. Do the same results occur if we have a connection-oriented transport instead of a datagram transport? I reran the tests using TCP with a binary encoding rather than HTTP with a text encoding. You can see with this arrangement that efficiency is between 0.4 and 0.6 for all but the smallest sizes of reliable sessions. Even using a very large reliable session does not significantly change the efficiency. These results fit very well with the rule of thumb. This only reinforces the point that measurements are only significant when taken against the application being optimized. Any change to how the service works can greatly affect the results. Next time: Endpoints with Multiple Schemes Read More...
|
-
What kind of a performance impact does ensuring reliable delivery have? A common rule of thumb that I've heard circulated in the past is that turning on a feature such as reliable messaging or security cuts your throughput roughly by half. I decided to put this rule of thumb to a test by taking some measurements. I instrumented a simple service to collect data over the course of many calls. I used HTTP. I used custom bindings to match up exactly the same settings both with and without reliable sessions. All of this is completely irrelevant because your service has different message sizes, different processing times, a different network, or what have you. Your service simply won't have the same numbers. Nevertheless, I looked at the data and decided how to best organize it. The striking feature was how much (or in some cases how little) the throughput impact changed when I varied the number of messages in each reliable session. Rather than give you numbers with unhelpful units, I created a unitless measure by dividing the throughput with reliable messaging on by the throughput with reliable messaging off. As you can see, the throughput was roughly cut to a third when the sessions were ridiculously small and recovered to around 90% when the sessions were ridiculously large. I think that for reasonably sized sessions though, a number between 50 and 75 percent would not be out of the question. The rule of thumb seems pessimistic. These measurements were taken under conditions where none of the packets were actually dropped of course. The efficiency gets worse if you need to retransmit something. However, it's meaningless to consider dropped packets when one part of the measurement is non-reliable transfer. Non-reliable transfer doesn't work when packets are dropped. You can make something extremely fast if it doesn't need to be correct. Next time: Measuring Reliable Session Speed with Duplex Read More...
|
-
How can I use reliable messaging together with a load balancer? The point of reliable messaging is to help ensure that messages get from one place to another. This means that the protocol notices when messages that were expected to be delivered go missing. On the other hand, the point of a load balancer is to make sure that messages are spread out and that there aren't too many messages going to the same place. You can see how these two goals might come into conflict at times. Many load balancers do offer a compromise to make these two goals simultaneously achievable though. A perfect load balancer would take the total sum of messages delivered and divide those messages evenly up among the available processing nodes. However, assume that the number of messages in any one client session is relatively small compared to the total number of messages processed. A load balancer could instead apportion groups of messages among the available processing nodes where the total sum of messages is still split roughly equally. This division according to groups would allow a feature like reliable messaging to work because the same server would be used to process all of the messages in the reliable session. The feature that this division method represents is typically called "sticky sessions" or some other phrase for affinitization in the load balancer. Next time: Local Settings and Policy Read More...
|
-
I thought I posted this right after the ratification announcement, but evidently I ran Spot the Intern instead. WS-ReliableMessaging 1.1 is the OASIS standardized version of the protocol for transferring messages reliably despite node or network failures. Reliable Messaging includes duplicate detection and elimination, message ordering, and guaranteed message delivery. WCF can make use of Reliable Messaging for recovering from network failures although the implementation today doesn't include support for recovering from node failures. The Orcas release of WCF has updates for this newly ratified standard. You can get a copy of the WS-ReliableMessaging 1.1 standard from the OASIS website. Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.1 Web Services Reliable Messaging Policy Assertion (WS-RM Policy) Version 1.1 Next time: There's no post for the 4th of July. Read More...
|
-
Why doesn't increasing the InactivityTimeout of a reliable session keep client connections alive for longer? When using a reliable session, there are two different inactivity timers that must be satisfied to keep the connection alive. If either inactivity timer goes off, then the connection is killed. The first inactivity timer is on the reliable session and is called InactivityTimeout. This inactivity timer fires if no messages, either application or infrastructure, are received within the timeout period. An infrastructure message is a message that is generated for the purpose of one of the protocols in the channel stack, such as a keep alive or an acknowledgment, rather than containing application data. The second inactivity timer is on the service and uses the ReceiveTimeout setting of the binding. This inactivity timer fires if no application messages are received within the timeout period. Since the connection is killed if either inactivity timer fires, increasing InactivityTimeout once it is greater than ReceiveTimeout has no effect. The default for both of these timeouts is 10 minutes, so you always have to increase ReceiveTimeout first to make a difference. Next time: Glossary Updates 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...
|
-
In the channel development series last week, we looked at the characteristics of channels (protocol channels, transport channels, and why you would write a channel at all). Let's use a specific example to illustrate those points. Although the protocol for reliable messaging is quite complex, the basic intent of the channel can be described quite simply. We'll keep the discussion simpler by only talking about the send side of the server response. You can map this yourself to the client side or to receiving messages, but this example doesn't need a lot of details to get the point across. Here's a channel stack that contains the reliable messaging channel. When the server sends a message out to the client, that message passes through the upper protocol channels in the channel stack. Those protocol channels can create, alter, or destroy messages along the way, but let's say that the message arrives intact to the reliable messaging channel. The reliable messaging channel first makes a copy of the message just in case delivery fails in the future. The reliable messaging channel then sends the message down through the remaining protocol channels. Again, we'll assume that nothing happens along the way; the message gets to the transport and is sent over the network. Sometimes, despite the best efforts of this process, the client never receives the message. In that case, the reliable messaging channel will produce another copy of the message from its store and send it again. Eventually, the client will either acknowledge receipt of the message or the two sides will decide to give up due to their inability to communicate. When the message is acknowledged, the reliable messaging channel throws its copy away as the message is no longer needed. Let's check against the criteria for writing channels to see if a channel was really needed to perform reliable messaging. Did we need a new component that interfaces with the network? No, there was some other component in the channel stack that handled the network for us. Did we need to establish a pattern of message exchange? Yes, the pattern of retries and acknowledgement is something that's different from the exchange inherent in a service call. Did we need to have a protocol for expressing the messages? Yes, although we didn’t talk about the details of that protocol in this example. We need some way of describing what data is, what acknowledgments are, and when retries are occurring. Did we need something other than a one-to-one Read More...
|
|
|
|