About trusted sessions in WCF

A few days ago, a friend asked about the reliable session in WCF on QA. Today, I will repeat it to find out the role, methods, and practical significance of trustworthy sessions.

As with that doubt, many friends who have worked in WCF development do not quite understand reliablesession. After reading msdn, we can see that reliablesession is a class in the namespace of system. servicemodel. The main functions are as follows:

Provides convenient access to the reliable session binding element attributes, which are provided at the moment of using the binding provided by the system.

Includes two important property members:

1. inactivitytimeout

This document describes how to get or set the time interval for the service to remain inactive before it is disabled.

To put it bluntly, if the service remains idle for a long time, we will close it, after a long time, the boss will fire you !)

2. Ordered

This document describes how to get or set a value that indicates whether message transmission must be in the same order as message sending.

Either the client sends the request message or the server sends the Response Message ). Messages are sent in order. When the receiver receives these messages, there may be misorders. Some messages may be sent first, while others may be sent first, this affects the normal interaction between the communication parties. There are two main reasons for this phenomenon:

1) no reliable connection protocol is used, which causes a similar phenomenon in the transport layer.

2) Although the reliable connection protocol has been tried, there is a sequential problem in sending or receiving through the channel at the sender or receiver.

TCP is used to solve the first problem, while the ordered of reliabelsession can solve the second problem.

 

In the default binding of WCF, only the following features are supported or the reliablesession function is enabled by default. They are:

Wshttpbinding

Wsdualhttpbinding

Wsfederationhttpbinding

Nettcpbinding

Among them, the reliablesession attribute in nettcpbinding, wshttpbinding, and wsfederationhttpbinding is a derived type of relibalesession, called optionrelibalesession, which provides optional functions. Compared with reliablesession, optionreliablesession only has one attribute: enabled, which can be used to indicate whether to enable a trusted session. True indicates that it is enabled. If false, it is disabled. The inactivitytimeout and ordered settings are invalid. Here, both wshttpbinding and wsfederationhttpbinding are inherited from wshttpbindingbase. When we discuss reliablesession, the two bindings share the same performance. However, for the request with wsdualhttpbinding, the ordered of the reliablesession attribute is set to true by default. That is to say, wsdualhttpbinding supports trusted sessions by default. The default value of inactivitytimeout in reliablesession is 10 minutes.

In the description of the reliablesession, we can clearly see the convenient description. How is this happening? The class reliablesession does not have a default constructor, but only has a structure that receives the reliablesessionbindingelement type. This leads to a more important role: reliablesessionbindingelement. next, let's talk about it and how it relates to the reliablesession and the binding.

Reliablesessionbindingelement:

A derived class of bindingelement, that is, it is a binding element. If you are familiar with the WCF architecture or have read the <WCF Follow-Up Tour> of hero artech, you should know how the WCF foundation works. It doesn't matter if you don't know it. I would also like to say that what WCF exposes to the outside world is an endpoint. In the basic department of WCF, an endpoint consists of three main parts: 1) address (Address) 2) binding 3) contract (contract), that is, the legendary "ABC. The address is relatively simple, and the contract is used by the WCF framework for developers to create specific business logic.CodeThe core and most attractive part of WCF is binding. The understanding of BIND can help us better understand some features of WCF. A binding maintains a set of bindelement, which is expressed as the elements attribute in the mbinding derived class of the binding. elements is the type of a collection <bindingelement>. Each bindingelement in elements has its own functions. For example, in nettcpbinding, this bindingelement organization method exists.

Transactionflowbindingelement is in the first position. If reliablesession is supported, reliabelsessionelement is in the second position of nettcpbinding. If reliablesession is not supported, this element will exist, followed by securitybindingelement, next, binarymessageencodingbindingelement is used for message encoding, followed by an element for communication security. Its type is determined by the nettcpsecurity attribute. Finally, tcptransportbindingelement. Note that in each binding, the last element must be a transportbindingelement. In the bindingelement mentioned above, each of them has its own functions. They perform their respective duties. binding only closely organizes them together. But is every bindingelement a real performer? No! He is also an organizer and has two main objects in his organization:

Channelfactory

Channellistener

The channelfactory is used as the client, and the channellistener is used as the server. Unfortunately, both channelfactory and channellistener are not really executors. They are the factory classes of ichannel. The channel object of ichannel is actually implemented through hard work. As for how channelfactory and channellistener organize the channel and some specific behaviors of the channel, the length is limited and will not be repeated. In order to give you a detailed understanding, I drew several pictures:

Next, we will expand the final point and express the detailed structure of the endpoint in graphs:

Bindingelement manages two objects: channelfactory and channellistener

The following figure shows the representation of this level:

After talking about so many infrastructor related to the WCF infrastructure, let's look at the reliablesessionelement. First, we will understand it from a macro perspective. It is a type of bindingelement, it contains the following main attribute members:

Inactivitytimeout

Ordered

Maxretrycount

Among the preceding important attributes, the inactivitytimeout and ordered attributes are consistent with those of reliabelsession. Maxretrycount is used to specify the number of times that a trusted channel is used, that is, when ordered is set to true, when the trusted channel does not receive the message, it is used to call the send method on the basic channel to resend the message.

Reliabelsession is a quick representation of reliablesession, because when binding is constructed, a reliablesessionelement object is constructed first, and then the reference of this object is passed to the reliablesession object, in this case, the reliablesession object is actually part of the data in the reliablesessionelement object. It is only because the reliabelsessionelement is exposed to the developer and is not elegant, so a reliablesession class is designed separately for quick expression of reliablesessionelement.

Well, theoretically, the reliablesession I know is similar. Next, we will use an interesting example to test the function of reliablesession. What are the similarities and differences between using it and not using it.

The idea of this experiment comes from the book windowscommunicationfoundation unleashed <WCF secrets>. Legend has it that the idea of this example comes from the WCF Project Manager shy Cohen. his idea is to divide an image into 100 points, each of which is sent to the receiver as a message. The receiver is generating an image based on the received message. During the sending process, a custom binddingelement is inserted to intercept the probability of Data split and the data will not be sent. At this time, if the reliablesession is not used, the image received by the receiver is incomplete. A small part is missing. If reliablesession is used, even though the message is not sent when it is intercepted at the time of sending, however, the basic channel will try to resend the packet, and there is a small chance that the resend packet will be intercepted again. If it is intercepted again, it will resend again, and the chances of being intercepted will be lower, at this time, the recipient receives the complete image.

In the shy Cohen test, there are three components:

Sender)

Receiver)

Comparison (router)

Relationship between them

The comparison can specify the ratio of spammers, such as 1% and 10%. The comparison always uses a session without a reliable connection. The test procedure is as follows:

1) First, set the receiver and sender to not accept trusted sessions. The setting method is to add <reliablesession ordered = "false"/> in the respective config. At this time, run threeProgramIn the comparison, adjust the packet loss frequency and select an image from the sender. Note: it is best to set the value of "seattle.jpg" in the example, because other images may be too large and cause exceptions. Select an image and click send. In this case, the number of received packets, the number of lost packets, and the number of sent packets are displayed in the comparison and receiver. If the set ratio is large, the image is obviously missing. The number of packet loss in the comparison is greater than 0.

Through this step, we can conclude that if a trusted session is not used, messages may be lost or misplaced during transmission, even though we use the TCP protocol.

2) change the configuration in the receiver and sender config to <reliablesession ordered = "true"/>. Then, select the image and send it again, and you will find that, the sending operation is very slow, but after the sending is complete, the recipient's image is complete, and the control still has some lost messages.

Through this experiment, we can clearly express the functions and meanings of trusted sessions. Here is an introduction. For more details, see chapter 4 <WCF secrets>.