筆者在讀程式碼初期非常想理清楚的就是ceph這麼個系統在服務端與客戶端是怎麼響應與發起請求的。

本人主要負責monitor部分，而且追了一會cephx認證的程式碼，所以拿這塊舉例，後續osd部分主要是對同事分享的學習。

本篇會講到src/mon/monitor.cc中

class Monitor : public Dispatcher

class MonClient : public Dispatcher 

以及src/tools/ceph.cc

這三者的關係：

前一篇講到ceph-mon.cc中啟動了monitor的程序，而啟動的過程伴隨著一些訊息佇列的啟動：

void SimpleMessenger::ready()

{

  ldout(cct,10) << "ready "<< get_myaddr()<< dendl;

  dispatch_queue.start();//訊息接收佇列啟動

  lock.Lock();

  if (did_bind)

    accepter.start();//套接字啟動（如前一篇所說）

  lock.Unlock();

}

細節就不多說了，在entry()中我們可以看到有個while迴圈輪訓監聽，處理monitor接受到的請求，接下來是monitor對單條訊息的處理：

2. monclient

monclient

  // we only care about these message types
  switch (m->get_type()) {
  case CEPH_MSG_MON_MAP:
  case CEPH_MSG_AUTH_REPLY:
  case CEPH_MSG_MON_SUBSCRIBE_ACK:
  case CEPH_MSG_MON_GET_VERSION_REPLY:
  case MSG_MON_COMMAND_ACK:
  case MSG_LOGACK:
    break;
  default:
    return false;
  }

3. src/tools/ceph.cc

說到這裡，ceph.cc還沒出場，這裡引入一個容易混淆的概念：

比如說我在終端輸入ceph mon dump，這個時候發生了什麼？這是一個向monitor請求的命令，而且是客戶端發起的，是不是會例項化一個monclient，這個命令如何對應到程式碼中？

答案是，這個命令直觀的看，跟monclient沒有半毛錢關係（其實後面認證的時候有關係），它的入口是src/tools/ceph.cc（其實0.65版本之後不是了，後面會說明），這段程式碼的邏輯如下：

4. 總結

src/tools/ceph.cc是命令列的入口，而monclient是一個抽象的概念，在需要跟monitor打交道的時候，而且是處理上面所說的那幾種訊息的時候才會用到。

另外，從0.65版本後ceph.cc棄用了，你可以file /usr/bin/ceph  或者是/usr/local/bin/ceph，變成了個python指令碼，但是處理邏輯差不多