CHROME-IPC Introduction

The following knowledge points are more messy, follow-up: The following code is taken from the previous version of CHROMIUM34 channel monitoring + processing

Because Chrome's base library and IPC code are relatively small, use chrome for the IPC package
Chrome uses a well-known pipeline to communicate:
See: src\ipc\ipc_channel_win.cc

BOOL Channel::channelimpl::createpipe (const ipc::channelhandle &channel_handle,
                                      mode mode) {

BOOL Channel::channelimpl::P rocessconnection () {
 ....
  BOOL OK = connectnamedpipe (Pipe_, &input_state_.context.overlapped);

As can be seen from the above code, Chrome uses the channel class to encapsulate the famous pipe, the base class of channel is as follows:

Class Channel::channelimpl:public Internal::channelreader, public
                             Messageloopforio::iohandler {--
typedef base::messagepumpforio::iohandler Iohandler;
--Channelreader::channelreader (channel::listener* Listener)

Channel passes two base classes to achieve the following functions:
1.Listener processing receives the specific implementation, specifically by the channel users to achieve
The 2.messagepumpforio::iohandler is the IO completion port, and the caller only gives the handle of the IO object to the Messageloopforio object (Messagepumpforio:: Registeriohandler), Whenever an Io object's operation is completed, the caller receives a callback notification (iohandler::oniocompleted) from Messageloopforio, which is equivalent to watcher
that is, the channel can receive a callback when the message arrives and call listener to handle the Iohandler

Only one thread operates the channel, that is, the IO thread channelproxy across threads

As mentioned earlier, the always IO thread that operates the channel, but basically we need to communicate from non-IO threads to other processes, what is chrome best at? Task, right, put the operation of the channel on the task, then post the task to the IO thread queue, and chrome encapsulates a proxy layer Ipc\ipc_channel_proxy.h

Class Ipc_export Channelproxy:public Message::sender {

Its base class is Message::sender, that is, it is the sender, combined with the above watcher, listener, the complete chain formed
It posttask the message to the IO thread by the following function

BOOL Channelproxy::send (message* Message) {
 ...
  Context_->ipc_message_loop ()->posttask (
      from_here,
      base::bind (&channelproxy::context::o Nsendmessage,
                 Context_, Base::P (scoped_ptr<message> (Message))));
  return true;
}
---->
//called on the Ipc::channel thread
void Channelproxy::context::onsendmessage (scoped_ptr< Message> message) {
  if (!channel_.get ()) {
    onchannelclosed ();
    return;
  }
  if (!channel_->send (Message.release ()))
    onchannelerror ();
}

If you want to send a sync message, use Syncchannel, it is actually on the basis of channelproxy to add a wait, but why not called Syncchannelproxy it.

Class Ipc_export Syncchannel:public Channelproxy,
Public Base::waitableeventwatcher::D elegate {

The Channelproxy is constructed as follows:

Initializes a channel proxy. The Channel_handle and mode parameters are
Passed directly to the underlying ipc::channel. The listener is called on
The thread that creates the Channelproxy. The filter ' s onmessagereceived
method is called the thread in where the Ipc::channel is running. The
Filter May was null if the consumer is not interested in handling messages
On the background thread. Any message isn't handled by the filter would be
Dispatched to the listener. The given message loop indicates where the
Ipc::channel should be created.
Channelproxy (const ipc::channelhandle& Channel_handle,
Channel::mode Mode,
Channel::listener* Listener,
base::messageloopproxy* Ipc_thread_loop);

Note the fourth argument, which allows us to implement the subclass of messageloopproxy ourselves to forward the message to the thread we createdMessage Macros

Chrome's message is divided into two categories, routing (routed) and control, the routing message is private, the system will follow the routing information to the safe delivery of the message to the destination, no one can peek; control messages are a broadcast message, who wants to hear and hear. So the external package uses the control message directly, Chrome's message macro expansion is anti-human, it allows to define a macro, expand multiple pieces of code, so there is no #pragma once, the following is the IPC message definition used by DM:

 #include "ipc/ipc_message_macros.h" #define Ipc_message_start channelmsgstart IPC_STRUCT_  BEGIN (channelmsg_messagecontent) ipc_struct_member (std::vector<unsigned char>, body) ipc_struct_member (bool, 
    Reply_flag)//Response flag, whether the answer message Ipc_struct_member (Int32, reply_id)//sync serial number Ipc_struct_end ()///<summary> The client requests the service-side proxy to assign a service to it and returns the name of the server//</summary> ipc_sync_message_control0_1 (channelmsg_clienthost RequestService, std::string)///<summary>//Client Query the service side for pipeline ID//</summary> ipc_sync_mes
    Sage_control0_1 (Channelmsg_clientqueryid,int32)//<summary>//Control message//</summary> Ipc_message_control2 (Channelmsg_routingmessage, Int32,//Target/sender host ID channelmsg_messagecontent) 

#define IPC_MESSAGE_IMPL
#include "ipc_msgcrack.h"

//Generate constructors.
#include "ipc/struct_constructor_macros.h"
#include "ipc_msgcrack.h"

//Generate destructors.
#include "ipc/struct_destructor_macros.h"
#include "ipc_msgcrack.h"

//Generate param traits write methods.
#include "Ipc/param_traits_write_macros.h"
namespace IPC 
{
#include "ipc_msgcrack.h"
}// namespace IPC

//Generate param traits read methods.
#include "Ipc/param_traits_read_macros.h"
namespace IPC 
{
#include "ipc_msgcrack.h"
}// Namespace IPC

Sync indicates a synchronous call, and send returns when it waits for a reply, 0_1 represents 0 in,1 out
Eg:channelmsg_clientqueryid, indicating out a int32 (channel ID to be queried)

More details can be found in ipc\ipc_message_macros.h channelproxy::messagefilter early intercept message

The function that receives the message, by default is the Ipc::channel::listener->onmessagereceived function, similar to MFC's map mechanism, but we can set the filter intercept message, if filter intercepts and processes a message, You won't get to ipc::channel::listener->onmessagereceived.

  Class Ipc_export MessageFilter
      : Public Base::refcountedthreadsafe<messagefilter, messagefiltertraits> {
    ....
    Return true to indicate the message is handled, or false to let
    //The message is handled in the default.
    virtual bool onmessagereceived (const message& Message);

Set Filter to use
·
Ordinarily, messages sent to the Channelproxy is routed to the matching
Listener on the worker thread. This API allows code to intercept messages
Before they is sent to the worker thread.
If you call this before the target process is launched and then you ' re
Guaranteed to not miss any messages. If you call the anytime after,
Then some messages might be missed since the filter was added internally on
The IO thread.
void AddFilter (messagefilter* filter);
void Removefilter (messagefilter* filter);

Follow-up supplement

Reference:

http://blog.csdn.net/qhh_qhh/article/details/49077579
http://blog.csdn.net/farrellcn/article/details/51088936