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

还是在学校时间比较多, 能够把时间更多的花在学习上, 尽管工作对人的提升更大, 但是总是没什么时间学习, 而且工作的气氛总是很紧凑, 忙碌, 少了些许激情吧。适应就好了.延续着之前对twisted高并发框架的学习, 自己重新写了一遍代码, 并开始在程序中实现自己的一些想法, 并不局限于最基本的操作, 以及官网上的实例, 因此就引出来了今天的问题.首先, 我需要阐述下我的想法:
在命令行下启动twisted的服务器端程序, 以及客户端程序.同时在客户端程序中传入三个命令行参数, 其中一定要有close命令, 比如我的传参就是: hello Ryan close.此close控制着连接, 也就是说, 对close参数处理的结果就是关闭服务器-客户端的连接.我原本的设想是分批处理的, understand? 就是说分别对这三个参数进行处理, 前两个参数直接输出就可以, close参数就处理服务器-客户端的连接.但是, 天不随我愿, 先看看代码:
服务器端:
# coding=utf-8
from twisted.internet.protocol import Protocol
from twisted.internet.protocol import Factory
from twisted.internet.endpoints import TCP4ServerEndpoint
from twisted.internet import reactor clients = [] class Spreader(Protocol): # 派生自协议的协议类
def __init__(self, factory):
self.factory = factory
self._data_buffer = bytes() # 处理粘包 def connectionMade(self):
self.factory.numProtocols = self.factory.numProtocols + 1
self.transport.write(
"欢迎来到Spread Site, 你是第%s个客户端用户!\n" % (self.factory.numProtocols)
)
clients.append(self) def connectionLost(self, reason):
self.factory.numProtocols = self.factory.numProtocols - 1
clients.remove(self)
print "lost connect: %d" % (self.factory.numProtocols) def dataReceived(self, data):
print " ** dataReviced ** "
print data.decode('utf-8') self._data_buffer += data
print self._data_buffer
if self._data_buffer.find('close') == -1:
print "loseConnection..."
self.transport.loseConnection()
else:
# self.transport.write(data + " " + "got it!")
# print len(clients)
for client in clients:
print "no--lose " + self._data_buffer
client.transport.write(self._data_buffer + " " + "got it") class SpreadFactory(Factory): # 继承自Factory的自定义协议工厂类
def __init__(self):
self.numProtocols = 0 def buildProtocol(self, addr):
return Spreader(self) # 生成协议 endpoint = TCP4ServerEndpoint(reactor, 8007)
endpoint.listen(SpreadFactory()) # 开启监听...
reactor.run()
客户端:
# coding=utf-8
from twisted.internet.protocol import Protocol, ClientFactory
from twisted.internet import reactor
from time import sleep
import sys class Echo(Protocol):
def __init__(self):
self.connected = False def connectionMade(self):
self.connected = True def connectionLost(self, reason):
self.connected = False # 因为transport是非线程安全的, 多访问下可能会引起错误
def routine(self, factory, _d):
# sys.argv[0]获取本身文件路径, 不加索引表示命令行参数 sys.argv其实就是一个元组, 表示用户输入的参数
sleep(1.5)
if factory.protocol and factory.protocol.connected:
print " ** routine ** "
print _d.decode('utf-8')
factory.protocol.transport.write(_d) # transport为非线程安全函数, 最好调用callfromThread def dataReceived(self, data):
print " ** dataReviced ** "
print data.decode('utf-8') for index in range(len(_data)):
_d = _data[index]
self.routine(factory, _d)
# reactor.callFromThread(self.routine, factory, data)
# routine(factory) class EchoClientFactory(ClientFactory):
def __init__(self):
self.protocol = None def startedConnecting(self, connector):
print "Start to Connect..." def buildProtocol(self, addr):
print "Connected..."
self.protocol = Echo()
return self.protocol def clientConnectionLost(self, connector, reason):
print "Lost connection. Reason: ", reason def clientConnectionFailed(self, connector, reason):
print "Connection is failed, Reason: ", reason host = '127.0.0.1'
port = 8007
factory = EchoClientFactory() # 自定义协议工厂对象
reactor.connectTCP(host, port, factory) # 开启TCP连接
# threading.Thread(target=routine, args=(factory,)).start() # 开启一个线程去执行
_data = sys.argv[1:4]
reactor.run()
运行截图:
服务器端:
客户端:
我们分析下正好可以得到, 客户端的确是分开发送三个参数的, 但是服务器端的dataReviced函数却是全盘接受, 这就很霸道了。看来我需要在twisted好好地淘淘宝了, 一开始出现这个问题, 我以为是我程序有问题, 搞得我重新研究了twisted的基本通信, 发包, 中断处理...
好吧, 在这里贡献下我找的资料, 个人觉得twisted网上的资源还是比较少, 去官网吧, 表示找起来很懵逼, 尽管四级过了, 而且网不行...
twisted高并发库transport函数处理数据包的些许问题的更多相关文章
- Winpcap笔记4之不用回调函数捕获数据包
函数1: pcap_next_ex(pcap_t* p, struct pcap_pkthdr** pkt_header, const u_char* ...
- 记一次高并发场景下.net监控程序数据上报的性能调优
最近在和小伙伴们做充电与通信程序的架构迁移.迁移前的架构是,通信程序负责接收来自充电集控设备的数据实时数据,通过Thrift调用后端的充电服务,充电服务收到响应后放到进程的Queue中,然后在管理线程 ...
- Lwip lwip_recvfrom函数一个数据包不能分多次读取。
最近在写一个基于Lwip协议栈的网络程序,对于一包数据,想先获得包头信息,再根据包头信息读取后面的数据,但是调用recvfrom后,发现读取后面的数据读取不到,进一步查阅发现,原来对于UDP协议,一次 ...
- java之高并发与多线程
进程和线程的区别和联系 从资源占用,切换效率,通信方式等方面解答 线程具有许多传统进程所具有的特征,故又称为轻型进程(Light—Weight Process)或进程元:而把传统的进程称为重型进程(H ...
- Java架构-高并发的解决实战总结方案
Java架构-高并发的解决实战总结方案 1.应用和静态资源分离 刚开始的时候应用和静态资源是保存在一起的,当并发量达到一定程度的时候就需要将静态资源保存到专门的服务器中,静态资源主要包括图片.视频.j ...
- JAVA架构师眼中的高并发架构,分布式架构 应用服务器集群
前言 高并发经常会发生在有大活跃用户量,用户高聚集的业务场景中,如:秒杀活动,定时领取红包等. 为了让业务可以流畅的运行并且给用户一个好的交互体验,我们需要根据业务场景预估达到的并发量等因素,来设计适 ...
- Entity Framework入门教程(13)---EF中的高并发
EF中的高并发 这里只介绍EF6中database-first开发方案的高并发解决方案,code-first开发方案中的高并发会在以后的EF CodeFirst系列中介绍. EF默认支持乐观并发:我们 ...
- python数据包之利器scapy用法!
scapy介绍: 在python中可以通过scapy这个库轻松实现构造数据包.发送数据包.分析数据包,为网络编程之利器! scapy安装: pip install scapy ======> ...
- Linux 中的网络数据包捕获
Linux 中的网络数据包捕获 Ashish Chaurasia, 工程师 简介: 本教程介绍了捕获和操纵数据包的不同机制.安全应用程序,如 VPN.防火墙和嗅探器,以及网络应用程序,如路由程序,都依 ...
随机推荐
- 详解EBS接口开发之库存事务处理采购接收--补充
除了可以用 详解EBS接口开发之库存事务处理采购接收的方法还可以用一下方法,不同之处在于带有批次和序列控制的时候实现方式不同 The script will load records into ...
- 使用Geolocation校正GDAL不支持的数据
对于低分数据来说,常用的校正方式就是给定数据的经纬度查找表来进行校正.在GDAL中,这种校正方式叫Geolocation array.常用的数据有国外的MODIS数据,国内的如风云系列(FY)和海洋系 ...
- 5.QT中关于HTTPClient相关的操作,Json数据传输
新建项目T12HttpClient T12HttpClient.pro SOURCES += \ main.cpp QT += network CONFIG += C++11 main.cpp ...
- ubuntu常用文件搜索命令
1.find find [搜索路径] [搜索关键字] 比如查找/test中文件名为t5.tmp的文件: 查找根目录下大于100M的文件 注意,这里的204800单位是块,1块=512字节 在根目录下查 ...
- Fetch XML and ConditionExpression operators
https://msdynamicscrmblog.wordpress.com/2013/05/10/fetch-xml-and-conditionexpression-operators-using ...
- 为什么会存在using filesort
当使用explain分析SQL时常常会遇到extra的其中一值为using filesort,如: PRIMARY KEY (`id`), KEY `uid` (`uid`) explain se ...
- (NO.00003)iOS游戏简单的机器人投射游戏成形记(十四)
我们首先必须将Level中所有机器人保存在某个数组里,因为该数组会在不同地方被访问,我们将其放在LevelRestrict类中,按道理应该放到GameState类中,这里从简. 打开LevelRest ...
- (NO.00003)iOS游戏简单的机器人投射游戏成形记(七)
因为到目前为止我都是在iOS模拟器中测试,但即便如此,也觉得按住手臂旋转时,手臂转动起来比较费劲,很难停止在玩家期望的位置上.因为手臂完全通过物理引擎的计算来移动,它有自身的惯性影响,所以很难控制. ...
- StoreType.java 存储方式
StoreType.java 存储方式 http://injavawetrust.iteye.com package com.iteye.injavawetrust.miner; /** * 存储方式 ...
- leetcode之word ladder
对于之前没有接触过该类型题目的人来说,此题无疑是个难题,本人提交了10次才正确通过,期间遇到了非常多的问题,感觉几乎把OJ的所有错误遍历了一遍,下面详细说说自己做该题的经验. 首先承认,我一开始并没有 ...