【问题标题】:What am I doing wrong with sendline() in my twisted server?我在扭曲的服务器中使用 sendline() 做错了什么?
【发布时间】:2012-04-01 00:11:46
【问题描述】:

我正在尝试一次将文件的内容发送到客户端 1 行 以便客户端(用 Objective-C 编写)可以单独处理每一行。 但是客户端的日志显示数据是从服务器发送过来的 全部通过 1 条线,显然太大,所以它切断了中间 由于意外的语法,通过一行导致客户端崩溃。

我在服务器上做的事情(用 python 写的)是 导致线路不单独发送?

这是服务器中目前让我无法工作的特定代码。

def sendLine(self, line): 
    self.transport.write(line + '\r\n') 

def updateShiftList(self):

    #open the datesRequested file for the appropriate store and load the dates into a list
    fob = open('stores/'+self.storeName+'/requests/datesRequested','r')
    DATES_REQUESTED = fob.read()
    datesRequested = DATES_REQUESTED.split('\n')
    #open each date file that is listed in datesRequested
    for date in datesRequested:
        if os.path.isfile('stores/'+self.storeName+'/requests/' + date):
            fob2 = open('stores/'+self.storeName+'/requests/' + date,'r')
            #load the file into memory and split the individual requests up
            THE_REQUESTS = fob2.read()
            thedaysRequests = THE_REQUESTS.split('\n')
            for oneRequest in thedaysRequests:
                if len(oneRequest) > 4:
                    print "*)[*_-b4.New_REQUEST:"+oneRequest
                    self.sendLine('*)[*_-b4.New_REQUEST:'+oneRequest)
            fob2.close()
    fob.close()

太令人沮丧了,我相信这很容易。谢谢。

【问题讨论】:

  • 感谢 DSM,没有使用 sendline 只是因为我一直在尝试其他方法来查看它是否改变了输出。我更新了代码以反映这一点,并在文件上添加了正确的关闭。谢谢。即使在该方法之前启动的另一个方法中的另一行中,这些行仍在合并在一起。

标签: python twisted


【解决方案1】:

这个问题涉及一个经常被提出的话题。 stackoverflow 上有很多关于同一问题的问题:

等等

TCP 发送有序、可靠的数据。

  • 排序意味着先发送的字节先到达。
  • 可靠性意味着发送的字节将被传递,否则连接将中断。数据不会被静默丢弃。

流媒体是您最关心的问题。流不被分成单独的消息。它由字节组成,这些字节之间的“边界”可以任意移动。

如果您发送“hello”,然后发送“world”,则流中这两个字符串之间的边界可能会消失。对等点可能会收到“hello, world”或“h”、“ello, world”或“he”、“ll”、“o”、“w”、“or”、“ld”。

这正是人们使用面向行的协议的原因。每个逻辑消息末尾的“\r\n”让接收者缓冲并将流拆分为那些原始逻辑消息。

为了更深入地了解,我推荐这个最近 PyCon 演示的视频:http://pyvideo.org/speaker/417/glyph

这一切都指向您连接的另一端,即 ObjC 客户端,这是您不当行为的根源。

【讨论】:

  • 我想说声谢谢。我通过玩代码得出了这个结论(客户是问题),但是当你不是 100% 确定如何做你想做的事情时,很难知道要问的正确问题.你真的帮助了我,给了我一些很好的资源。再次感谢您!
  • 我现在在客户端处理的一个问题是 1448 字节的流中断,我读到这对于某些 NIC 或类似的东西来说是一个正常的断点,并且看起来你的回答澄清了我对可能发生的事情的挥之不去的想法。因此,我将在客户端缓冲区上工作,知道流是有序且可靠的,谢谢,再次感谢。
猜你喜欢
  • 1970-01-01
  • 2012-11-27
  • 1970-01-01
  • 1970-01-01
  • 2014-11-18
  • 1970-01-01
  • 2018-05-22
  • 1970-01-01
  • 2020-08-30
相关资源
最近更新 更多