Browse by Tags

• Answers
• Indigo
• Networking
• Service Model

• Waiting for Ready Channels

  When I create a channel to a service, how do I know when the service is ready to process the data for that channel? A channel doesn't really know what the service is doing. The service might be actively processing the data being sent over the channel. Or, the service might not. There is a constant tension in the system between components that want to push data and components that want to pull data. Components that push data actively work as long as there is data available until a back pressure builds up in the system that resists their ability to push. This back pressure is typically the result of some queue or buffer that has filled up and is no longer able to accept the things being pushed into it. Components that push include several transport and protocol channels, as well as the service dispatcher that pushes messages to the service implementation. Components that pull data remain quiescent even if data is available until there is someone that actually wants to consume some data. Many transport and protocol channels pull messages rather than push. A single implementation may feature both push and pull modes. For example, the TCP channel has a small portion that works in a push mode for connection establishment and transferring some initial data while the application portion of TCP works in a pull mode. Depending on the visibility of these push and pull modes, you might be able to tell from the behavior of a particular protocol what the service is doing. For example, if you're using just TCP, then the initial transmissions needed to open a connection can only be completed once a little bit of pulling has been done on the receiving application side, thus telling you that the service is doing some active processing. On the other hand, if you're using a ReliableMessaging channel or a OneWay channel, then those protocols have a visible running state where they are in push mode. You can't actually tell whether the service is working until you fill up some of the buffers in the protocol stack and start getting push back in the form of rejected messages. That means the service is not working as fast as you're sending data. A queued channel would be an extreme example of push mode. A message queue allows you to push large amounts of data when the service is not even running. Therefore, to know in the general case whether the service is ready to process for you, you need to be able to ask that question to the service rather than to the channel. Next time: Composing Read More... Posted Tuesday, September 02, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Networking, Indigo, Channels, Answers, Service Architecture, Service Model

• Pull Not Push

  There are two architectural models for moving messages through a system. Pull messaging models require the receiver to actively suck messages out of the pipeline in order to achieve flow. If the receiver is not willing to perform work, then there's nothing the sender can do to move messages around. Push messaging models automatically generate work on the receiving end when a sender transmits a message. It's then the responsibility of the receiver to process these work items before system capacity is reached (in many systems, there is some programming ease-of-use to make the work items automatically expire after some period of negligence by the receiver). Real messaging systems have many architectural layers stacked on top one another, some of which are push and some of which are pull. Just the process of sending a packet of data using TCP requires several protocol layers of pushing and pulling. You may have noticed that the channel stack of WCF represents a pull model. Actually, you may not have noticed this because the service layer of WCF represents a push model. Even some parts of the channel stack push instead of pull. For instance, the arrival of new client connections at an endpoint is a push operation. Clients will attempt to connect even if the service is not ready to listen for them. However, the service has to engage in some pulling to transform those client connection attempts into transport channels. The boundary from a push layer to a pull layer is a queue. Quota settings on the queue define the system capacity for how much outstanding work is tolerated and how long work should wait in the queue before being expired. The boundary from a pull layer to a push layer is a message pump. Quota settings on the message pump define how aggressively the pump operates. The channel stack uses a pull model because it's very convenient from a framework perspective. Pull models allow the user to explicitly control resources without having to define lots of complicated policy. Work only happens in a pull model when the user takes action, so the messaging system can simply idle when it doesn't have the capacity to accept additional work. Pull models are also convenient for error handling because there is always user code to which we can report any errors. If we don't have user code, then we need policy to dictate how errors are handled. Whenever you're writing channels, you need to keep the pull model in mind or else you will end up writing lots of fragile layer Read More... Posted Monday, November 06, 2006 8:19 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Channels, Service Architecture