我有一个客户端使用一对套接字与单个服务器通信:
context = zmq.Context()
socket = context.socket(zmq.PAIR)
socket.setsockopt(zmq.SNDTIMEO, 1000)
socket.connect("tcp://%s:%i"%(host,port))
...
if msg != None:
try:
socket.send(msg)
except Exception as e:
print(e, e.errno)
程序每秒发送大约一条 10 字节消息。我们发现程序最终会开始无限挂起以等待消息发送,因此我们添加了 SNDTIMEO。然而,现在我们开始得到 zmq.error.Again 。一旦我们收到此错误,该资源将永远不再可用。我正在研究到底发生了哪些错误代码,但我通常想知道人们使用什么技术从程序中的 zmq.error.Again 中恢复。我应该破坏套接字连接并重新建立它吗?
最佳答案
事实#0:PAIR/PAIR
与其他 ZeroMQ 原型(prototype)不同
RFC 31 明确定义:
Overall Goals of this Pattern
PAIR
is not a general-purpose socket but is intended for specific use cases where the two peers are architecturally stable. This usually limitsPAIR
to use within a single process, for inter-thread communication.
接下来,如果没有正确设置SNDHWM
大小,并且如果想要使用PAIR
来操作tcp://
-transport-class 也是所有与 O/S 相关的 L3/L2 属性,任何接下来的 .send()
也会产生 EAGAIN
错误。
还有一些额外的对策(CONFLATE
、IMMEDIATE
、 HEARTBEAT_{IVL|TTL|TIMEOUT}
),但是 PAIR/PAIR
存在上述主要限制,它设置了使用此原型(prototype)时不会发生的情况.
主要嫌疑人:
考虑到上述设计方面的限制,传输路径损坏,PAIR
接入点将不会重新协商将套接字重建到 RTO 中-状态。
因此,如果您的代码确实希望继续使用 PAIR/PAIR
,那么明智的做法是还组装一条紧急 SIG/标志路径,以允许 distributed-system能够稳健地应对此类 L3/L2/L1 事件,而 PAIR/PAIR
已知不会自动处理。
尾声:
您的代码不使用非阻塞.send()
模式,而EAGAIN
错误状态恰好用于发出信号通过设置EAGAIN
来阻止功能(此时接入点无法.send()
)。
更好地使用已发布的 API 详细信息:
aRetCODE = -1 # _______________________________________ PRESET
try:
aRetCODE = socket.send( msg, zmq.DONTWAIT ) #_______ .SET on RET
if ( aRetCODE == -1 ):
... # ZeroMQ: SIG'd via ERRNO:
except:
... #_______ .HANDLE EXC
finally:
...
关于python - 在 zmq.PAIR 套接字上从 zmq.error.Again 中恢复,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49222514/