IOCP(IO完成端口)是一种伸缩性的IO模型,广泛应用于各种类型的高性能服务器,如Apache等。 IO完成端口,应用程序使用线程池处理异步IO请求的一种机制。 最初设计: 应用程序发出一些异步IO请求,设备驱动把这些工作项目排序到完成端口,在完成端口上等待线程池便可以处理这些完成IO。 完成端口实际上是一个WINDOWS IO结构,可以接收多种对象的句柄。 1 创建完成端口对象
__in HANDLE ExistingCompletionPort,
----- By PiggyXP(小猪)
这篇文档我非常详细并且图文并茂的介绍了关于网络编程模型中完成端口的方方面面的信息,从API的用法到使用的步骤,从完成端口的实现机理到实际使用的注意事项,都有所涉及,并且为了让朋友们更直观的体会完成端口的用法,本文附带了有详尽注释的使用MFC编写的图形界面的示例代码。
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) 本人很多年前接触完成端口以来,期间学习和练习了很多次,本以为自己真正地理解了其原理,最近在看网狐的服务器端源码时又再一次拾起完成端口的知识,结果发现以前理解的其实很多偏差,有些理解的甚至都是错误的。网络上关于windows完成端口的介绍举不胜举,但大多数都是介绍怎么做,而不是为告诉读者为什么这么做。看了很多遍小猪的讲解:
系列目录 关于windows完成端口(IOCP)的一些理解(一) 关于windows完成端口(IOCP)的一些理解(二) 关于windows完成端口(IOCP)的一些理解(三) 关于windows完成端口(IOCP)的一些理解(四) 关于windows完成端口(IOCP)的一些理解(五) 关于windows完成端口(IOCP)的一些理解(六) 本人很多年前接触完成端口以来,期间学习和练习了很多次,本以为自己真正地理解了其原理,最近在看网狐的服务器端源码时又再一次拾起完成端口的知识,结果发现以前理解的其实很多
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) 下面给出上文中使用到的对完成端口模型封装的类的全部代码: /* ========================================================================== Purpose: * 这个类CIOCPModel是本代码的核心类, 用于说明W
最近,由于基础框架的整体升级,因此需要更新所有相关项目的DLL文件。这个过程存在不小的风险,因此也对发布后的生产服务器进行了密切的监控,结果还是出现了个别应用出现异常的情况,很快的占用了大量的服务器内存和CPU等资源。通过研究dump,初步发现是由于配置服务器出现单点故障,然后应用通过多线程调用相关SOA服务时出现异常,引发了ThreadAbortException异常,而且由于原有异常处理代码不够严谨,而且与异步发送报警邮件紧密结合在一起,造成线程数量的几何级增加,最终使得整个服务器不可用。这儿介绍的不算
一、背景 进入多核时代已经很久了,大数据概念也吵得沸沸扬扬,不管你喜欢不喜欢,不管你遇到没遇到,big-data或bigger-data都必须正视. 处理大数据,基本都离不开分布式计算和分布式
一、背景 进入多核时代已经很久了,大数据概念也吵得沸沸扬扬,不管你喜欢不喜欢,不管你遇到没遇到,big-data或bigger-data都必须正视. 处理大数据,基本都离不开分布式计算和分布式存储,这
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) #include "StdAfx.h" #include "IOCPModel.h" #include "MainDlg.h" // 每一个处理器上产生多少个线程(为了最大限度的提升服务器性能,详见配套文档) #define WORKER_THREADS_PER_PROCESSOR 2 // 同时投
系列目录 关于windows完成端口(IOCP)的一些理解(一) 关于windows完成端口(IOCP)的一些理解(二) 关于windows完成端口(IOCP)的一些理解(三) 关于windows完成端口(IOCP)的一些理解(四) 关于windows完成端口(IOCP)的一些理解(五) 关于windows完成端口(IOCP)的一些理解(六) #include "StdAfx.h" #include "IOCPModel.h" #include "MainDlg.h" // 每一个处理器上产生
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) // 最后释放掉所有资源 void CIOCPModel::_DeInitialize() { // 删除客户端列表的互斥量 DeleteCriticalSection(&m_csContextList); // 关闭系统退出事件句柄 RELEASE_HANDL
本篇是异步编程系列的第三篇,本来计划第三篇的内容是介绍异步编程中常用的几个方法,但是前两篇写出来后,身边的朋友总是会有其他问题,所以决定再续写一篇,作为异步编程(一)和异步编程(二)的补充。
在Windows上创建进程是一件很容易的事,但是在管理上就不那么方便了,主要体现在下面几个方面: 1. 各个进程的地址空间是独立的,想要在进程间共享资源比较麻烦 2. 进程间可能相互依赖,在进程间需要进行同步时比较麻烦 3. 在服务器上可能会出现一个进程创建一大堆进程来共同为客户服务,这组进程在逻辑上应该属于同一组进程 为了方便的管理同组的进程,Windows上提供了一个进程池来管理这样一组进程,在VC中将这个进程池叫做作业对象。它主要用来限制池中内存的一些属性,比如占用内存数,占用CPU周期,进程间的优先级,同时提供了一个同时关闭池中所有进程的方法。下面来说明它的主要用法
Start函数用于开启服务 1 初始化状态变量 2 创建监听套接字 3 加载使用扩展API函数 4 创建完成端口对象 5 建立监听套接字和完成端口对象间的关联 6 为监听套接字注册FD_ACCEPT时间 7 投递AcceptEx IO不够时可以得到通知后创建监听线程 BOOL CIOCOPServer::Start(int nPort,int nMaxConnnections,int nMaxFreeBuffers,int nMaxFreeContexts,int nInitialReads) {
在一般的设计中,当需要一个线程时,就创建一个,但是当线程过多时可能会影响系统的整体效率,这个性能的下降主要体现在:当线程过多时在线程间来回切换需要花费时间,而频繁的创建和销毁线程也需要花费额外的机器指令,同时在某些时候极少数线程可能就可以处理大量,比如http服务器可能只需要几个线程就可以处理用户发出的http请求,毕竟相对于用户需要长时间来阅读网页来说,CPU只是找到对应位置的页面返回即可。在这种情况下为每个用户连接创建一个线程长时间等待再次处理用户请求肯定是不划算的。为了解决这种问题,提出了线程池的概念,线程池中保存一定数量的 线程,当需要时,由线程池中的某一个线程来调用对应的处理函数。通过控制线程数量从而减少了CPU的线程切换,而且用完的线程还到线程池而不是销毁,下一次再用时直接从池中取,在某种程度上减少了线程创建与销毁的消耗,从而提高效率 在Windows上,使用线程池十分简单,它将线程池做为一个整体,当需要使用池中的线程时,只需要定义对应的回调函数,然后调用API将回调函数进行提交,系统自带的线程池就会自动执行对应的回调函数。从而实现任务的执行,这种方式相对于传统的VC线程来说,程序员不再需要关注线程的创建与销毁,以及线程的调度问题,这些统一由系统完成,只需要将精力集中到逻辑处理的回调函数中来,这样将程序员从繁杂的线程控制中解放出来。同时Windows中线程池一般具有动态调整线程数量的自主行为,它会根据线程中执行任务的工作量来自动调整线程数,即不让大量线程处于闲置状态,也不会因为线程过少而有大量任务处于等待状态。 在windows上主要有四种线程池 1. 普通线程池 2. 同步对象等待线程池 3. 定时器回调线程池 4. 完成端口回调线程池
客户IO处理,是在工作线程,_WorkerThreadProc中完成的 函数,在完成端口上调用GetQueuedCompletionStatus函数等待IO完成,并调用自定义函数HandleIO来处理IO,具体代码如下: DOWRD WINAPI CIOCPServer::_WorkerThreadProc(LPVOID lpParam) { #ifdef _DEBUG ::OutputDebugString("Worker Thread startup...\n"); #e
之前写了关于Winsock的重叠IO模型,按理来说重叠IO模型与之前的模型相比,它的socket即是非阻塞的,也是异步的,它基本上性能非常高,但是它主要的缺点在于,即使我们使用历程来处理完成通知,但是我们知道历程它本身是在对应线程暂停,它借用当前线程的线程环境来执行完成通知,也就是说要执行完成通知就必须暂停当前线程的工作。这对工作线程来说也是一个不必要的性能浪费,这样我们自然就会想到,另外开辟一个线程来执行完成通知,而本来的线程就不需要暂停,而是一直执行它自身的任务。处于这个思想,WinSock提供了一个新的模型——完成端口模型。
举个例子,在高峰期去餐厅吃饭,会先排队拿个小票,然后去逛一下玩玩,等到排到时会被通知就餐,这时再回到餐厅就可以点餐了。
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) 1 不知道你是否记得前面中说过每消耗一个预先准备客户端的socket,就要补上一个。这个代码现在看来就应该放在连接成功事件里面了: DWORD ThreadFunction() { OVERLAPPED *pOverlapped = NULL; PER_SOCKET_CON
我非常认同一图胜千言的说法,因此我也喜欢用图来解释各种技术概念。本文通过图解来说明 .NET 中 async/await 如何工作。
系列目录 windows完成端口(一) windows完成端口(二) windows完成端口(三) windows完成端口(四) windows完成端口(五) windows完成端口(六) 1 现在还剩下最后一个问题,就是工作线程如何退出。当然你可以在每次判断标识位前先判断一个退出标识。但是如果工作线程正好被GetQueuedCompletionStatus挂载那里呢?如何唤醒,微软提供了另外一个函数:PostQueuedCompletionStatus,看下这个函数的签名: BOOL WINAPI Pos
系列目录 关于windows完成端口(IOCP)的一些理解(一) 关于windows完成端口(IOCP)的一些理解(二) 关于windows完成端口(IOCP)的一些理解(三) 关于windows完成端口(IOCP)的一些理解(四) 关于windows完成端口(IOCP)的一些理解(五) 关于windows完成端口(IOCP)的一些理解(六) 1 现在还剩下最后一个问题,就是工作线程如何退出。当然你可以在每次判断标识位前先判断一个退出标识。但是如果工作线程正好被GetQueuedCompletionStat
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
原文链接:https://www.cnblogs.com/DOMLX/p/9661012.html
本文主要说明在Windows下操作文件的高级方法,比如直接读写磁盘,文件的异步操作,而文件普通的读写方式在网上可以找到一大堆资料,在这也就不再进行专门的说明。
容器中可以运行一些网络应用,要让外部也可以访问这些应用,可以通过 -P 或 -p 参数来指定端口映射。
a) iocp 是完全线程安全的,即同时可以有多个线程等待在 iocp 的完成队列上;
eos代码更新很快,在4月初已经升级到3.0版本,随着版本的更迭,在各个操作系统下的编译、节点的运行都越来越集成化,不需要自己再一步步的下载依赖,如果感兴趣可以直接按照官方wiki进行编译。官方wiki地址:https://github.com/EOSIO/eos/wiki
在前段时间检查异常连接导致的内存泄漏排查的过程中,主要涉及到了windows异步I/O相关的知识,看了许多包括重叠I/O、完成端口、IRP、设备驱动程序等Windows下I/O相关的知识,虽然学习到了很多东西,但是仍然需要自顶而下的将所有知识进行梳理。
主线程创建监听套接字,创建额外工作线程,关联IOCP,负责等待和接受到来的连接。 调用GetQueuedCompletionStatus函数,函数返回: 1 调用失败 2 套接字被对方关闭 3 请求成功完成 程序首先定义per-handle per-IO的操作数据的结构类型 #define BUFFER_SIZE 1024 typedef struct _PER_HANDLE_DATA{ SOCKET s; sockaddr_in addr; }PER_HANDLE_DATA,*PPER_H
关于IOCP网上到处都是资料,说的也很详细。我在这里就不再多说了,这只是本人在学习IOCP时的笔记,和配合AcceptEx写的一个极小的服务端程序。由于刚刚接触ICOP加上本人刚毕业不到一年,所以里面的理解或观点可能有误,还请大家多多批评!
WSASocket 无管道正向CMD,使用WSASocket函数创建一个TCP套接字,并绑定到一个本地地址和端口上。然后使用CreateProcess函数创建一个新的CMD进程,并将标准输入、输出和错误输出重定向到套接字的句柄上。这样,客户端可以通过网络连接到这个套接字,发送CMD命令并获取命令输出结果。这种方式称为无管道正向CMD,因为CMD进程的输入输出是通过套接字而非管道进行的。
2. IO操作: CPU会把内存中的程序委托给其他的网络、磁盘等驱动程序,让这些外部的驱动程序来进行具体的处理,处理完成以后再返回给内存程序。对于这两类操作的优化方式是不一样的。内存操作的特点是占用CPU资源,CPU不断的计算。对于内存密集型的操作(Compute-Bound Operation)的优化,我们可以把一个大任务拆分成多个互不影响的子任务,那么就能让多个CPU同时参与运算,最后合并子任务的结果,所花的时间自然就少了。所以内存密集型的操作(Compute-Bound Operation)的优化有一个前提:超线程、多核、甚至是真正的多个CPU的计算机能够同时运行多个线程,对于只有一个CPU的计算机不适合。多线程之间的状态切换是需要额外的CPU资源的。IO操作的特点是基本不占用CPU资源,但是它会占用当前的工作者线程,并使其进入等待状态,等待IO完成的处理结果,然后在继续执行。但是在ASP.NET这种天然多线程的环境里,CLR线程池容量是有上限的,这个上限也代表了应用程序最多可以同时执行的请求数量。如果我们CLR线程池的所有线程都进入了IO等待状态,当再有新用户进来,我们的服务就停止响应了。目前我们IO操作的缺点是当前工作者线程同步等待IO,任何IO处理都会霸占一条工作者线程。所以对于IO密集型的操作(IO-Bound Operation)的优化,我们的思路是使用IOCP(I/O Completion Port)。IOCP翻译了中文是IO完成端口,它是一种异步形态,原理是这样的:当前工作者线程在进行IO处理时,委托给某个设备驱动程序,然后自己返回线程池,当IO完成后,OS会通过IOCP提醒CLR它工作已经完成,当CLR接收到通知后,会唤醒一个I/O线程并且运行用户的回调。
和往常一样,我开始使用修补程序修改的二进制文件的BinDiff(在这种情况下只有一个:TermDD.sys)。下面我们可以看到结果。
这是从零学习开源项目的第四篇,上一篇是《从零学习开源项目系列(三) CSBattleMgr服务源码研究》,这篇文章我们一起来学习LogServer,中文意思可能是“日志服务器”。那么这个日志服务器到底做了哪些工作呢?
IOCP底层机理还没有透彻的理解,现将部分内容记录如下 2014.7.22 16:50
我拒绝了这一说明,直到概念验证(PoC)公之于众,以免造成任何伤害。现在Github上有多个拒绝服务的PoC,我发布了我的分析。
这一章介绍如何在 Docker 内部以及容器之间管理数据,在容器中管理数据主要有两种方式:
之前在博客已经介绍过几款常用端口转发程序,比如rinetd和Nginx Stream,今天继续介绍的是另一个端口转发程序brook relay,话不多说先看效果图。
在上一篇文章在chromev8中的JavaScript事件循环分析中分析到,在chrome中的js引擎是通过执行栈和事件队列的形式来完成js的异步操作。然而在node中,事件循环表现出的状态与浏览器中大致相同。不同的是node中有一套自己的模型。node中事件循环的实现是依靠的libuv引擎。我们知道node选择chrome v8引擎作为js解释器,v8引擎将js代码分析后去调用对应的node api,而这些api最后则由libuv引擎驱动,执行对应的任务,并把不同的事件放在不同的队列中等待主线程执行。 因此实际上node中的事件循环存在于libuv引擎中。
最近因为毕设在搭建接口及数据库环境,使用Apache+MySQL+PHP在阿里云ECS服务器中配置,之前在本地配置过并成功实现,但是在阿里云中却频频出错,记录下配置过程中遇到的坑,方便后来人借鉴参考!
我们都知道,javascript从诞生之日起就是一门单线程的非阻塞的脚本语言。这是由其最初的用途来决定的:与浏览器交互。
代码部分疑惑说明 说明:①WSAAcceptEx函数作用是投递accept操作到完成端口内核,只有该函数可以完成此功能
https://github.com/gongluck/Windows-Core-Program.git
前面两节课,我们着重分析了 initAndRegister方法,对通讯通道的创建、初始化以及注册到选择器上有了一个详细的介绍,回想JDK NIO的开发步骤,我们需要获取SocketChaennel、获取选择器Selector、将通道注册到选择器、绑定端口、处理事件!那么同样的Netty是基于NIO开发的,也同样少不了这几个步骤,迄今为止,我们已经学习了,Selector的创建、SocketChannel的创建、选择器的注册,今天我们要学的就是通道的绑定端口!
领取专属 10元无门槛券
手把手带您无忧上云