在編寫一個使用C++ socket實現的TCP服務端與客戶端小軟體時接連碰上2個小陷阱，

終歸是實踐不足，基本功不紮實。

第1個問題： 服務端的accept函式沒有阻塞

    程式執行到accept這裡時直接就跳了過去，根本沒停下來。

    懷疑過socket的配置是否有錯誤，經過各種除錯，當把socket部分的程式碼從工程中截取出，單獨放到一個空白工程中執行時，一切又都正常了。

    證實了socket的配置沒有問題，只能是原工程中的哪個標頭檔案包含後把socket的函式覆蓋了。

    又經過了幾次試驗，最終定位到了罪魁禍首竟然是using namespace std

    網上查了一下才知道原來這也是個常見問題。因為std的名稱空間裡包含了太多常用的函式名，當全域性使用std名稱空間時，很容易發生函式執行沒有得到預期的效果。

    在socket的這個問題中，重要的bind函式被std中的同名函式覆蓋，使得服務端的socket沒有繫結ip地址和商品，自然之後的accept函式也就不能正常阻塞。

     對策有2種，

     1是把bind函式改為全域性呼叫方式  ::bind()， 擺脫std名稱空間的影響。 

     2是放棄std名稱空間在全域性範圍內的宣告，改用指定使用函式的方式。 如 using std::cout 或using std::endl

第2個問題：客戶端socket斷開後重連失敗

    這是在測試的時候發現的問題。這次的小軟體設計是客戶端在與服務端保持TCP連線的過程中可以隨意向服務端傳送命令。操作結束後可以暫時斷開TCP連線，當有需求時再次連線。

    因此客戶端的處理框架是迴圈等待使用者輸入，再根據內容來判斷需要向服務端發起什麼樣的操作請求。

  WORD wVersionRequested;
  WSADATA wsaData;
  int err;
  SOCKET sockClient;

  wVersionRequested = MAKEWORD(1, 1);

  err = WSAStartup(wVersionRequested, &wsaData);
  if (err != 0) {
    return;
  }

  if (LOBYTE(wsaData.wVersion) != 1 ||
    HIBYTE(wsaData.wVersion) != 1) {
    WSACleanup();
    return;
  }
  sockClient = socket(AF_INET, SOCK_STREAM, 0);

  SOCKADDR_IN addrSrv;

  inet_pton(AF_INET, "127.0.0.1", &addrSrv.sin_addr.s_addr);

  addrSrv.sin_family = AF_INET;
  addrSrv.sin_port = htons(6000);


  while (1)
  {
    char in_buf[40];
    string input_command;

    cin >> in_buf;

    input_command = in_buf;

    if (input_command.compare("TCP connect") == 0)
    {
      connect(sockClient, (SOCKADDR*)&addrSrv, sizeof(SOCKADDR));
      char recvBuf[500]; recv(sockClient, recvBuf, 500, 0);
      printf("%s\n", recvBuf);

    }
    else if (input_command.compare("operation") == 0)
    {
      char requst_buf[40] = "operation";
      send(sockClient, requst_buf, strlen(requst_buf) + 1, 0);

      char recvBuf[500]; recv(sockClient, recvBuf, 500, 0);
      printf("%s\n", recvBuf);
    }

    else if (input_command.compare("disconnect") == 0)
    {
      char requst_buf[40] = "disconnect";
      send(sockClient, requst_buf, strlen(requst_buf) + 1, 0);

      char recvBuf[500]; recv(sockClient, recvBuf, 500, 0);
      printf("%s\n", recvBuf);

      closesocket(sockClient);
    }
}
 

這樣的客戶端程式碼在啟動後第一次連線服務端時一切都很正常，但在斷開後做再次連線時發生了異常，服務端並沒有收到再連線請求，一直停留在accept阻塞的位置。而客戶端卻能收到socket的資訊反饋，但進一步確認後發現也只能收到返回訊息，需要服務端處理的操作就無法得到服務端的響應。

這個現象就像是客戶端在做二次連線時，連線請求並沒有送到服務端，而只是把客戶端可能會收到的返回訊息作為快取放在socket中，給客戶端造成一種已經再次連線上的假象。

又經過一陣網路搜尋，原來這也是一種常見現象。已經連線過的socket資源不能直接用於再次連線，要麼對它做一次初始化，要麼再次生成一個新的socket資源。作為修改，我選擇了後者。

    if (input_command.compare("TCP connect") == 0)
    {
      WORD wVersionRequested;
      WSADATA wsaData;
      int err;

      wVersionRequested = MAKEWORD(1, 1);

      err = WSAStartup(wVersionRequested, &wsaData);
      if (err != 0) {
        return;
      }

      if (LOBYTE(wsaData.wVersion) != 1 ||
        HIBYTE(wsaData.wVersion) != 1) {
        WSACleanup();
        return;
      }

      SOCKET sockClient;
      sockClient = socket(AF_INET, SOCK_STREAM, 0);

      SOCKADDR_IN addrSrv;

      inet_pton(AF_INET, "127.0.0.1", &addrSrv.sin_addr.s_addr);

      addrSrv.sin_family = AF_INET;
      addrSrv.sin_port = htons(6000);

      connect(sockClient, (SOCKADDR*)&addrSrv, sizeof(SOCKADDR));
      char recvBuf[500]; recv(sockClient, recvBuf, 500, 0);
      printf("%s\n", recvBuf);

    }

把socket的建立程式碼移到發起TCP連線時才執行，保證每次發起連線請求用的都是新的socket，問題得到解決。