socket 如何確認(rèn)對端已經(jīng)close

kaede_1

最近糾結(jié)于兩個小問題，哪位大牛幫忙解答一下，不勝感激
1.客戶端給服務(wù)端發(fā)送消息，一端時間后服務(wù)端執(zhí)行了close操作，請問此時客戶端如何檢測到這一事件？ 如果檢測不到，再一次發(fā)送時會觸發(fā)broken pipe信號
2.在linux端進(jìn)行服務(wù)開發(fā)時，一般會用top查看占用的資源，不知各位一般習(xí)慣看哪幾個字段？我一般看cpu、mem、swap。VIRT那個字段有參考必要嗎？

shang2010

這個要看網(wǎng)絡(luò)方面的專家來解答了，

話說如果突然失去通信的這種，你也沒辦法，網(wǎng)絡(luò)如果又恢復(fù)了呢？？我隨便說說的

lxyscls

回復(fù) 1# kaede_1


    講錯，看來還是select(read) -> read = 0 -> close

kaede_1

回復(fù) 3# lxyscls


    write=-1 是嘛意思？我這邊測試，第一次client send之后，服務(wù)端接收后close，client端接下來在嘗試去發(fā)送，但是此時服務(wù)端已經(jīng)接收不到信息，再一次發(fā)送時觸發(fā)了signal broken pipe。
    我想問的就是，在服務(wù)端關(guān)閉之后，client端如何檢測到這一事件。

evaspring

看了好幾個網(wǎng)絡(luò)庫 都是通過 read() == 0 來判定連接斷開的

cokeboL

read write 返回值 + 心跳超時

有些時候，比如對方突然斷電，進(jìn)電梯信號沒了，尤其移動端，這些情況很常見，這些場景，只能心跳超時來判斷

lxyscls

回復(fù) 4# kaede_1


    恩，select讀事件吧，讀事件里面read = 0 close(fd)
    看了一下broken pipe的原因，記得是write兩次，第二次fd已經(jīng)收到rst，前面通過write=-1判斷不對

    http://linkyou.blog.51cto.com/1332494/751877

kaede_1

各位大牛，我指的是發(fā)送，而不是讀取。因此憑借read返回值為0來判斷是不行的

而且本地試過，服務(wù)端關(guān)閉連接后，客戶端第一次send的返回值是正常的，因此此時也不能通過send的返回值來判斷。

在網(wǎng)上查過，可以通過select和epoll來監(jiān)測rst信號，但是對于僅發(fā)送數(shù)據(jù)的客戶端來說又有點繁重。

想請教大牛們有沒有什么好方法，多謝！

wlmqgzm

//  我的檢測socket_closed的代碼
bool  Asio_tcp_socket::find_socket_closed( boost::asio::ip::tcp::socket &socket1, int int_socket_handle_init )
{
  int int_socket_handle = socket1.native_handle();
  if( int_socket_handle <= 0 )   {
    if( g_message_out_level>=5 )  log_message_int( "find socket closed. socket_init",  int_socket_handle_init );
    return true;
    }
  struct tcp_info info;
  int length = sizeof(info);
  memset( &info,0,sizeof(info) );
  getsockopt( int_socket_handle, IPPROTO_TCP, TCP_INFO, &info, (socklen_t *)&length );
  if( info.tcpi_state == 1 )   return false;
  if( g_message_out_level >=5 )   log_message_int( "find socket closed. socket_init",  int_socket_handle_init );
  return true;
}

lxyscls

回復(fù) 9# wlmqgzm


你這個是主動確認(rèn)，樓主的情況總不能write一下確認(rèn)一次吧