在套接字上使用 O_NONBLOCK 后，有没有办法避免 HUP？

Question

当我在阻塞模式下使用套接字时，我可以有一个简单的系统来做这样的事情：

client            server

A -------------------> B
      register

A <------------------> B
   (various messages)

A -------------------> B
      unregister

刚发送完unregister消息，进程A可以立即退出，而B却如期收到了消息。

如果我在 A 的套接字上打开非阻塞模式，B 永远不会收到 unregister 如果 A 发送该消息然后立即退出（我通过在发送 [=14 后添加 sleep(1) 进行测试=]，在那种情况下它会按预期工作。）因此，或多或少，我的客户无法完全取消注册。

注意：当 B poll() A 的套接字时，我收到挂断信号 (POLLHUP) 而不是最后一个 unregister 消息，然后挂断。

我试图添加一个调用来重新打开阻塞模式，但不知何故它没有任何区别。我使用以下代码更改阻塞模式：

int optval(0 or 1);
ioctl(get_socket(), FIONBIO, &optval);

为了以防万一，我也尝试使用 fcntl()，尽管我确信就内核而言调整了相同的标志。

int flags(fcntl(get_socket(), F_GETFL));
flags |= O_NONBLOCK;   // use this line to turn ON
flags &= ~O_NONBLOCK;  // use this line to turn OFF
fcntl(get_socket(), F_SETFL, flags);

附带说明一下，我使用 read() 和 write() 函数发送和接收消息。

更新：

对于那些感兴趣的人，测试现在在我们的 git:

服务器：https://sourceforge.net/p/snapcpp/code/ci/master/tree/snapwebsites/tests/test_shutdown_server.cpp
客户：https://sourceforge.net/p/snapcpp/code/ci/master/tree/snapwebsites/tests/test_shutdown_client.cpp

这些使用了snap库，主要是依赖tcp的snap_communicator client/server:

TCP: https://sourceforge.net/p/snapcpp/code/ci/master/tree/snapwebsites/lib/tcp_client_server.cpp
通讯员：https://sourceforge.net/p/snapcpp/code/ci/master/tree/snapwebsites/lib/snap_communicator.cpp

Answer 1

如您所见，套接字上的 send 仅对要发送的数据进行排队。这实际上并不意味着服务器得到了它。对于阻塞和非阻塞套接字都是如此。

几种可能性：

确保在客户端程序退出之前在套接字上调用 close。您没有在问题中说明是否发生了这种情况，但这可能是个好主意。
如果#1 不起作用，请在套接字上使用 SO_LINGER 选项。设置合适的超时时间间隔。

类似下面的内容

  struct linger ling;
  ling.l_onoff = 1;
  ling.l_linger = 3; // 3 second wait for data to finish being set.
  setsockopt(s, SOL_SOCKET, SO_LINGER, &ling, sizeof(ling));

#2 的替代方法是修改您的协议，以便客户端在关闭套接字并退出之前从服务器获得某种确认消息。或者为了简单起见，客户端在退出之前等待服务器关闭套接字。（recv 将在服务器关闭套接字时 return 0）

我的建议是确保您已实施#1。如果这不适合您，请评估#3。 #2，如果没有别的。

Answer 2

听起来您实际上并没有在退出前关闭套接字。在正常情况下，SO_LINGER 的所有恶作剧都是不必要的。

在套接字上使用 O_NONBLOCK 后，有没有办法避免 HUP？

Is there a way to avoid HUP once you used O_NONBLOCK on a socket?

c

sockets

linux

nonblocking