Custom Channel sink conquer Journey 2

 

Next to the previous article "Custom channel sinks conquered by me"

. Net Channel sink is a very systematic framework. After understanding the principles and main interfaces of custom Channel sink, the following content will discuss the knowledge of Channel sink, this is also the second step.

During my learning process, I have an experience to share with you: the learning process is a mountaineering process. You have to be down-to-earth, step by step, if you think this is slow, and you want to find a "quick success" method, there will be only one result, and you will never be able to climb up on your own, because there is no such method in the world.

Next I want to discuss how to create a channel sink. Channel sinks can be divided into two types: one is to work on the client, and the execution interface is iclientchannelsink; the other is to work on the server, and the execution interface is iserverchannelsink. Among the two interfaces, the most critical method is processmessage.

Let's take a look at the processmessage method definition of iclientchannelsink.
Void processmessage (
IMessage * MSG,
Itransportheaders * requestheaders,
Stream * requeststream,
[Out] itransportheaders ** responseheaders,
[Out] stream ** responsestream
);
MSG: Message to be processed
Requestheaders: the header information added to the external message sending service. The target is the server.
Requeststream: the byte stream sent to the transport layer.
The preceding three parameters are input parameters, which are used to send client data to the server. The following two parameters are the return parameters, which are used to return responses from the server.
Responseheaders: returned header information from the server
Responsestream: returns the stream from the transport layer.

let's look at the processmessage method definition of iserverchannelsink
serverprocessing processmessage (
Processing * sinkstack,
iMessage * requestmsg,
itransportheaders * requestheaders,
stream * requeststream,
[out] iMessage ** responsemsg,
[out] itransportheaders ** responseheaders,
[out] stream ** responsestream
);
sinkstack: the channel sinks stack called by the current Channel sink
requestmsg: Contains request cancellation Information
requestheaders: header information retrieved from the client message
requeststream: stream to be processed and then transmitted to the deserialization sink
the preceding three parameters are input parameters, which process the data sent from the client. The following three parameters are return parameters, the processing result of the server is the data to be returned to the client.
responsemsg: return the Server Response Message
responseheaders: return the header information sent to the client
responsestream: return the stream sent to the sink to the client.

From the above analysis, we can intuitively find that the processmessage method of the client and the processmessage method of the server constitute a message processing ring. The processing sequence is as follows: the client calls the proxy object-> [client sinks]. processmessage-> [server sinks]. processmessage-> Create a stack on the server to process data-> [server sinks]. processmessage-> [client sinks]. processmessage-> return value of the proxy object called by the client. In the above sequential expression, both the client and server processmessage are marked twice. In fact, they only run once, and the second annotation is actually the first call back, the returned value is the out parameter mentioned above.

---------------------------

In this section, I will write it here. It is still because of work reasons that I cannot calm down and write a blog. The reason why I wrote it here is that I want to pay attention to it. net remoting framework. The rest will be written next week. If you have any questions, contact me via QQ: 64528619. Thank you for your criticism!