Browse by Tags

• Indigo
• Networking
• Quotas
• Security
• Service Model
• TCP/IP

• Why Ordering is Ignored

  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... Posted Tuesday, March 25, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Reliable Messaging

• Silent Security Failures

  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... Posted Thursday, December 06, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 1 Comments Filed under: Indigo, Answers, Security, Reliable Messaging

• Sticky Sessions

  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... Posted Friday, July 13, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Networking, Indigo, Answers, Reliable Messaging

• Session Lifetime on the Server

  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... Posted Tuesday, June 26, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Answers, Reliable Messaging, Quotas, Service Model

• Socket Failures

  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... Posted Tuesday, April 24, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, TCP/IP, Answers, Reliable Messaging