twisted高并发库transport函数处理数据包的些许问题

还是在学校时间比较多, 能够把时间更多的花在学习上, 尽管工作对人的提升更大, 但是总是没什么时间学习, 而且工作的气氛总是很紧凑, 忙碌, 少了些许激情吧。适应就好了.延续着之前对twisted高并发框架的学习, 自己重新写了一遍代码, 并开始在程序中实现自己的一些想法, 并不局限于最基本的操作, 以及官网上的实例, 因此就引出来了今天的问题.首先, 我需要阐述下我的想法:
在命令行下启动twisted的服务器端程序, 以及客户端程序.同时在客户端程序中传入三个命令行参数, 其中一定要有close命令, 比如我的传参就是: hello Ryan close.此close控制着连接, 也就是说, 对close参数处理的结果就是关闭服务器-客户端的连接.我原本的设想是分批处理的, understand? 就是说分别对这三个参数进行处理, 前两个参数直接输出就可以, close参数就处理服务器-客户端的连接.但是, 天不随我愿, 先看看代码:
服务器端:

 1 # coding=utf-8
 2 from twisted.internet.protocol import Protocol
 3 from twisted.internet.protocol import Factory
 4 from twisted.internet.endpoints import TCP4ServerEndpoint
 5 from twisted.internet import reactor
 6
 7
 8 clients = []
 9
10
11 class Spreader(Protocol):  # 派生自协议的协议类
12     def __init__(self, factory):
13         self.factory = factory
14         self._data_buffer = bytes()  # 处理粘包
15
16     def connectionMade(self):
17         self.factory.numProtocols = self.factory.numProtocols + 1
18         self.transport.write(
19             "欢迎来到Spread Site, 你是第%s个客户端用户!\n" % (self.factory.numProtocols)
20         )
21         clients.append(self)
22
23     def connectionLost(self, reason):
24         self.factory.numProtocols = self.factory.numProtocols - 1
25         clients.remove(self)
26         print "lost connect: %d" % (self.factory.numProtocols)
27
28     def dataReceived(self, data):
29         print " ** dataReviced ** "
30         print data.decode(‘utf-8‘)
31
32         self._data_buffer += data
33         print self._data_buffer
34         if self._data_buffer.find(‘close‘) == -1:
35             print "loseConnection..."
36             self.transport.loseConnection()
37         else:
38             # self.transport.write(data + " " + "got it!")
39             # print len(clients)
40             for client in clients:
41                 print "no--lose " + self._data_buffer
42                 client.transport.write(self._data_buffer + " " + "got it")
43
44
45 class SpreadFactory(Factory):  # 继承自Factory的自定义协议工厂类
46     def __init__(self):
47         self.numProtocols = 0
48
49     def buildProtocol(self, addr):
50         return Spreader(self)  # 生成协议
51
52
53 endpoint = TCP4ServerEndpoint(reactor, 8007)
54 endpoint.listen(SpreadFactory())  # 开启监听...
55 reactor.run()

客户端:

 1 # coding=utf-8
 2 from twisted.internet.protocol import Protocol, ClientFactory
 3 from twisted.internet import reactor
 4 from time import sleep
 5 import sys
 6
 7
 8 class Echo(Protocol):
 9     def __init__(self):
10         self.connected = False
11
12     def connectionMade(self):
13         self.connected = True
14
15     def connectionLost(self, reason):
16         self.connected = False
17
18     # 因为transport是非线程安全的, 多访问下可能会引起错误
19     def routine(self, factory, _d):
20         # sys.argv[0]获取本身文件路径, 不加索引表示命令行参数  sys.argv其实就是一个元组, 表示用户输入的参数
21         sleep(1.5)
22         if factory.protocol and factory.protocol.connected:
23             print " ** routine ** "
24             print _d.decode(‘utf-8‘)
25             factory.protocol.transport.write(_d)  # transport为非线程安全函数, 最好调用callfromThread
26
27     def dataReceived(self, data):
28         print " ** dataReviced ** "
29         print data.decode(‘utf-8‘)
30
31         for index in range(len(_data)):
32             _d = _data[index]
33             self.routine(factory, _d)
34         # reactor.callFromThread(self.routine, factory, data)
35         # routine(factory)
36
37
38 class EchoClientFactory(ClientFactory):
39     def __init__(self):
40         self.protocol = None
41
42     def startedConnecting(self, connector):
43         print "Start to Connect..."
44
45     def buildProtocol(self, addr):
46         print "Connected..."
47         self.protocol = Echo()
48         return self.protocol
49
50     def clientConnectionLost(self, connector, reason):
51         print "Lost connection. Reason: ", reason
52
53     def clientConnectionFailed(self, connector, reason):
54         print "Connection is failed, Reason: ", reason
55
56
57 host = ‘127.0.0.1‘
58 port = 8007
59 factory = EchoClientFactory()  # 自定义协议工厂对象
60 reactor.connectTCP(host, port, factory)  # 开启TCP连接
61 # threading.Thread(target=routine, args=(factory,)).start()  # 开启一个线程去执行
62 _data = sys.argv[1:4]
63 reactor.run()

运行截图:

服务器端:

客户端:

我们分析下正好可以得到, 客户端的确是分开发送三个参数的, 但是服务器端的dataReviced函数却是全盘接受, 这就很霸道了。看来我需要在twisted好好地淘淘宝了, 一开始出现这个问题, 我以为是我程序有问题, 搞得我重新研究了twisted的基本通信, 发包, 中断处理...
好吧, 在这里贡献下我找的资料, 个人觉得twisted网上的资源还是比较少, 去官网吧, 表示找起来很懵逼, 尽管四级过了, 而且网不行...

twisted(2)--聊天系统

时间: 2024-10-05 17:40:44

twisted高并发库transport函数处理数据包的些许问题的相关文章

Winpcap笔记4之不用回调函数捕获数据包

函数1: pcap_next_ex(pcap_t*                       p, struct pcap_pkthdr**   pkt_header, const u_char*             pkt_data ) 从一个网络接口或离线捕获方式(例如读文件)读取一个数据包.该函数被用来重新获得下一个可用的数据包,没有使用libpcap提供的传统的回调方法.pcap_next_ex用指向头和下一个被捕获的数据包的指针为pkt_header和pkt_data参数赋值.

记一次高并发场景下.net监控程序数据上报的性能调优

最近在和小伙伴们做充电与通信程序的架构迁移.迁移前的架构是,通信程序负责接收来自充电集控设备的数据实时数据,通过Thrift调用后端的充电服务,充电服务收到响应后放到进程的Queue中,然后在管理线程的调度下,启动多线程进程数据处理. 随着业务规模的不断扩大和对系统可用性的逐步提高.现在这个架构存在很多的问题,比如: 1.充电服务重启,可能会丢数据. 2.充电服务重启会波及影响通信服务. 3.充电服务与通信服务面对的需求和变化是不一样,强依赖的架构带来很多的问题. 为了解决上述的这些问题,项目组

java700多个G架构师项目实战,高并发集群分布式,大数据高可用,视频教程获取方式

学习思路: 1.先学习第一套或者第二套架构师课程,帮助没有基础或基础学得不好的同学建立架构师思维,整套需要全部学习,很重要!! 2.根据工作需要,分别去学习第二套.第三套里的实战课程里的知识点,不需要全部全学习,那么多资料你没有那么多精力全部学完!! 对比内容: 本套课包含像Dubbo,Netty,Nio,Mina,Mecached,Nosql,MongoDB, Nginx, ActiveMQ等课程更全,我这里就不一一列举,亲们可以对比大小 本教程优势: 1.六套 架构师课程,基本包含了淘宝卖的

电商产品开发这些年,遇到的高并发架构坑儿

电商产品开发这些年,遇到的高并发架构坑儿 宇宙通用的镜子 百家号|03-04 14:21 关注 前言 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家. 服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务. 一个可以支持高并发的服

架构师眼中的高并发架构

前言 出处:https://my.oschina.net/u/3772106/blog/1793561 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家. 服务器架构 业务从发

支付宝架构师眼中的高并发架构

?阅读本文大概需要 11.4 分钟. 来源:my.oschina.net/u/3772106/blog/1793561 前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家.

[转帖]架构师眼中的高并发架构

架构师眼中的高并发架构 http://www.itpub.net/2019/04/25/1705/ 数据和云 2019-04-25 14:42:34 本文共6557个字,预计阅读需要17分钟. 前言 高并发经常发生在有大活跃用户量和用户高聚集的业务场景中,如:秒杀活动.定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过

支付宝架构师眼中的高并发

前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适合自己业务场景的高并发处理方案. 在电商相关产品开发的这些年,我有幸的遇到了并发下的各种坑,这一路摸爬滚打过来有着不少的血泪史,这里进行的总结,作为自己的归档记录,同时分享给大家. 服务器架构 业务从发展的初期到逐渐成熟,服务器架构也是从相对单一到集群,再到分布式服务. 一个可以支持高并发的服务少不

java之高并发与多线程

进程和线程的区别和联系 从资源占用,切换效率,通信方式等方面解答 线程具有许多传统进程所具有的特征,故又称为轻型进程(Light—Weight Process)或进程元:而把传统的进程称为重型进程(Heavy—Weight Process),它相当于只有一个线程的任务.在引入了线程的操作系统中,通常一个进程都有若干个线程,至少需要一个线程.下面,我们从调度.并发性. 系统开销.拥有资源等方面,来比较线程与进程. 1.调度 在传统的操作系统中,拥有资源的基本单位和独立调度.分派的基本单位都是进程.