python socketserver偶尔会停止发送(和接收?)消息
我编写的套接字服务器遇到了一个问题,其中套接字服务器似乎停止在它使用的一个端口上发送和接收数据(而另一个端口继续正常处理数据)。有趣的是,等待一分钟(或长达一个小时左右)后,套接字服务器将再次开始发送和接收消息,而无需任何可观察到的干预。
我正在使用 Eventlet 套接字框架 python 2.7,所有内容都在 ubuntu aws 实例上运行,外部应用程序打开与套接字服务器的持久连接。
从我一直在做的一些阅读来看,看起来我可能没有正确实现我的套接字服务器。 根据 http://docs.python.org/howto/sockets.html:
套接字的基本事实:消息必须是固定长度(恶心),或者是分隔的> > (耸耸肩),或者指出它们有多长(更好),或者通过关闭连接来结束。
我不完全确定我在这里使用的是固定长度消息(或者我是吗?)
这就是我接收数据的方式:
def socket_handler(sock, socket_type):
logg(1,"socket_handler:initializing")
while True:
recv = sock.recv(1024)
if not recv:
logg(1,"didn't recieve anything")
break
if len(recv) > 5:
logg(1,"socket handler: %s" % recv )
plug_id, phone_sid, recv_json = parse_json(recv)
send = 1
if "success" in recv_json and recv_json["success"] == "true" and socket_type == "plug":
send = 0
if send == 1:
send_wrapper(sock, message_relayer(recv, socket_type))
else:
logg(2, 'socket_handler:Ignoring received input: ' + str(recv) )
logg(1, 'Closing socket handle: [%s]' % str(sock))
sock.shutdown(socket.SHUT_RDWR)
sock.close()
“sock”是由listener.accept()函数返回的套接字对象。
socket_handler 函数的调用方式如下:
new_connection, address = listener.accept()
...<code omitted>...
pool.spawn_n(socket_handler, new_connection, socket_type)
我的实现对任何人来说都是不正确的吗?我基本上是在实施固定长度的对话协议吗?我可以做些什么来帮助调查问题或使我的代码更加健壮?
预先感谢,
T
I've been experiencing a problem with a socketserver I wrote where the socketserver will seem to stop sending and receiving data on one of the ports it uses (while the other port continues to handle data just fine). Interestingly, after waiting a minute (or up to an hour or so), the socketserver will start sending and receiving messages again without any observable intervention.
I am using the Eventlet socketing framework, python 2.7, everything running on an ubuntu aws instance with external apps opening persistent connections to the socketserver.
From some reading I've been doing, it looks like I may not be implementing my socket server correctly.
According to http://docs.python.org/howto/sockets.html:
fundamental truth of sockets: messages must either be fixed length (yuck), or be delimited > > (shrug), or indicate how long they are (much better), or end by shutting down the connection.
I am not entirely sure that I am using a fix length message here (or am I?)
This is how I am receiving my data:
def socket_handler(sock, socket_type):
logg(1,"socket_handler:initializing")
while True:
recv = sock.recv(1024)
if not recv:
logg(1,"didn't recieve anything")
break
if len(recv) > 5:
logg(1,"socket handler: %s" % recv )
plug_id, phone_sid, recv_json = parse_json(recv)
send = 1
if "success" in recv_json and recv_json["success"] == "true" and socket_type == "plug":
send = 0
if send == 1:
send_wrapper(sock, message_relayer(recv, socket_type))
else:
logg(2, 'socket_handler:Ignoring received input: ' + str(recv) )
logg(1, 'Closing socket handle: [%s]' % str(sock))
sock.shutdown(socket.SHUT_RDWR)
sock.close()
"sock" is a socket object returned by the listener.accept() function.
The socket_handler function is called like so:
new_connection, address = listener.accept()
...<code omitted>...
pool.spawn_n(socket_handler, new_connection, socket_type)
Does my implementation look incorrect to anyone? Am I basically implementing a fixed length conversation protocol? What can I do to help investigate the issue or make my code more robust?
Thanks in advance,
T
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您请求在服务器上接收的字节数 (1024) 多于实际从客户端发送的字节数,则可能会遇到与缓冲相关的问题。
为了解决这个问题,通常要做的就是首先对消息的长度进行编码,然后对消息本身进行编码。这样,接收方可以获得长度字段(大小已知),然后根据解码后的长度读取消息的其余部分。
注意:长度字段通常是协议中需要的字节数。有些协议是 4 字节对齐的,并为此使用 32 位字段,但如果您发现 1 或 2 字节就足够了,那么您可以使用它。这里的要点是客户端和服务器都知道该字段的大小。
You might be having buffering related problems if you're requesting to receive more bytes at the server (1024) than you're actually sending from the client.
To fix the problem, what's is usually done is encode the length of the message first and then the message itself. This way, the receiver can get the length field (which is of known size) and then read the rest of the message based on the decoded length.
Note: The length field is usually as many bytes long as you need in your protocol. Some protocols are 4-byte aligned and use a 32 bit field for this, but if you find that you've got enough with 1 or 2 bytes, then you can use that. The point here is that both client and server know the size of this field.