16th Talk about reliability sessions

Code

Https://yunpan.cn/cPns5DkGnRGNs Password: 3913

is not a special demo, we no longer post an example of the demo pictures, go directly to the net disk to find the corresponding project to see

Reliability:

Distributed, service-oriented systems can be affected by intermittent network failures, which can cause significant damage to the overall integrity of the system. The system must provide sufficient fault tolerance for the failure, and they must be able to recover from the failure in a controlled and predictable manner.

WCF provides 3 key features to improve overall reliability and predictability of communication between clients and servers , including:

1. Reliable sessions (reliable sessions can overcome transient network outages that occur on TCP, named pipelines, and HTTP. When a reliable session is enabled, if the service is unavailable, the client tries to resend the message. The advantage is that it is interoperable and therefore can be used to improve the reliability of HTTP messages. )

2. Support for transactions (transactional programmability allows developers to ensure that jobs can be completed as a single atomic transaction.) )

3. Message Queuing (when combined with transactions, queued messages provide a basis for durable, reliable, one-way communication, in which case the communication can remain connected over long network outages and machine restarts.) WCF uses Microsoft Message Queuing (MSMQ) to provide this type of reliability. )

Reliable sessions:

When you send a message to a remote service, the ideal situation is that you can be sure that the message has arrived there. If the message does not arrive, you may want to resend it and try again, at least to know if the message has never arrived in order to take corrective action. These delivery guarantees are provided by some transport protocols, such as TCP or named pipelines, but not by

provided by HTTP. Even so, with TCP and named pipelines, these guarantees are guaranteed only in point-to-point situations. If there is a middle tier between the sending and receiving applications, such as a proxy server or information router, there is no guarantee other than ensuring that the information in transit reaches the first network node.

Reliable sessions improve application reliability in the following ways:

1: It is guaranteed that the information is transmitted only once and in sequence, to protect against a brief interruption of the network connection.

2: These delivery guarantees are not binding with a certain protocol, thereby the reliability is possible for the HTTP protocol.

3: Reliability is based on the entire SOAP message, not just on individual IP packets.

There is no doubt that reliability is essential, but the decision to use a reliable session is often driven by the need to add reliability, which is not provided by the transport Protocol. Because of these drivers, you may selectively consider increasing the reliability of your TCP endpoints, but be sure to work towards reliable sessions of HTTP endpoints that do not have built-in transport guarantees. In general, reliable sessions are a good way to improve one-way information delivery guarantees because they do not provide a clear response to indicate success or failure.

To configure a reliability session:

1: Acknowledgment interval

This is a TimeSpan property that indicates the time that the receiver waits before sending a receive message acknowledgment, which is the default value of 0.2 seconds. This feature only affects bindings that support full-duplex communication. (used for duplex communication)

2: Flow control

This Boolean property is enabled by default. When enabled, the sending side will defer sending messages when the transmit window buffers on the receiving end are full. This reduces the number of necessary retry operations when the receive buffer is full and a incoming message cannot be processed.

3: Idle Timeout

This is a TimeSpan property that controls the duration of a reliable session. If no information is delivered during this time, the session fails. The default value is 00:10:00 (or 10 minutes).

4: Maximum Waiting channel

This int property is able to control the number of queued concurrent requests for a reliable session before rejecting a new request. The default value is 4.

5: Maximum Retry count

This int property controls the number of retry attempts by the sending side when a message is not acknowledged. The default value is 8, and the maximum can be configured to 20. This session fails when the retry count of a message is exhausted.

6: Maximum Transfer Size window

This int property controls the number of messages on the send or receive side buffers. On the sending side, the message is buffered for confirmation. At the receiving end, the messages are buffered and are optionally guaranteed in order. Its default value is 8.

7: The Orderly

This Boolean property is enabled by default, which means that messages are routed sequentially if a reliable session is enabled.

In most cases, the default values for these options should be sufficient. The most common change is to increase the idle timeout to better match the session expiration rules.

Standard bindings:

Some standard bindings support reliable sessions, especially nettcpbinding,wshttpbinding and wsdualhttpbinding.

Wsdualhttpbinding reliable sessions are always available, and you cannot turn them off.

NETTCPBINDING,WSHTTPBINDING2 bindings can be declared to support reliable sessions, which need to be added to the <reliableSession> node to the bound configuration.

As shown below:

1 <Wshttpbinding>2   <bindingname= "WSHTTPRM">3     <reliablesessionenabled= "true"ordered= "true"InactivityTimeout= "00:10:00"/>4   </binding>5 </Wshttpbinding>

Custom bindings:

To override the default method for other reliable session scenarios, you must create a custom binding. The following configuration shows how to create a reliable HTTP session. In this case, the,<reliablesession> element enables you to configure all the options:

1 <custombinding>2   <bindingname= "WSHTTPCUSTOMRM">3     <reliablesessionAcknowledgementinterval= "00:00:00.2000000"flowcontrolenabled= "true"InactivityTimeout= "00:10:00"Maxpendingchannels= "4"Maxretrycount= "8"maxtransferwindowsize= "8"ordered= "True/>"4 <textmessageencoding/>5     <HttpTransport/>6   </binding>7 </custombinding>

You might use a custom binding in the service to increase the size of the transmission window or the buffering of the channel waiting for the growing system load. Another reason might be to add a reliable session to a named pipeline channel.

The life cycle of a reliable session:

The life cycle of a reliable session is closely related to the life cycle of the initializing and receiving channels. For example, when a client agent is used to invoke a service, the client channel is created the first time the service is called. Similarly, on the first invocation, a service channel is created and a reliable session is published.

A reliable session ends when any of the following conditions occur:

1: The initiator destroyed its channel, for example, the agent was destroyed by the client.

2: The receive channel reaches the configured timeout time.

3: The originating or receiving channel enters an error state.

When the initiator destroys the channel, a series of messages are sent to the receiving end to formally terminate the reliable session. This is the most elegant way to terminate a reliable session because both parties are fully informed and able to close freely to clear any remaining buffer information.

In the traditional case, any form of session timeout is controlled by the bound receive timeout setting, which is passed to the reliable channel after it is created, so the following configuration causes the reliable session to time out after 5 seconds instead of the default of 10 minutes.

1 <Wshttpbinding>2   <bindingname= "WSHTTPRM">3     <reliablesessionenabled= "true"ordered= "true"InactivityTimeout= "00:00:05">4 </Wshttpbinding>

You can also explicitly set the idle timeout for the reliable session function of the binding. In this case, the shorter of the two timeout configurations will work.

For example, the result of the following configuration causes a reliable session to time out after 5 seconds:

1 <Wshttpbinding>2   <bindingname= "WSHTTPRM"ReceiveTimeout= "00:00:05">3     <reliablesessionenabled= "true"ordered= "true"InactivityTimeout= "00:10:00"/>4   </binding>5 </Wshttpbinding>

Try again

A re-attempt is an important feature of a reliable session. For example, if a network connection is temporarily interrupted, the initiator will attempt to resend each unrecognized message until the configured number of times limit is reached. This includes a retry to create a reliable session when the first call is made. If a retry attempt is reached for a specific message, the retry limit

, a reliable session is terminated by the start channel. Therefore, in order to control the number of retries, a custom binding is required because standard bindings do not provide access to this option.

Session Splitter

In the preceding we discussed the shunt technology, which allows you to conveniently control the load of the service. We explained how the MaxConcurrentSessions property of the Servicethrottle behavior controls the number of concurrent sessions that can be allocated in the service. This property can limit any type of session, including a reliability session.

For example, for a percall service that supports reliable sessions, the following settings will allow only 1000 reliable sessions to be active at the same time:

1 <  maxconcurrentcalls= " maxconcurrentinstances"= "+" MaxConcurrentSessions= "/> "

Here we'll see a demo of this lesson demo (1. Reliability session) Cloud disk

Carefully observe the configuration in the AppConfig

[16-01]

and test it yourself.

16th Talk about reliability sessions