tcp连接中的句柄是什么(无法获得连接句柄是什么意思)

用过 WinSock API 网友们知道：WinSock 编程中有一很方便的地方便是其 息驱动机制，不管是底层 API 的 WSAAsyncSelect() 还是 MFC 的异步Socket类：CAsyncSocket，都提供了诸如 FD_ACCEPT、FD_READ、FD_CLOSE 之类的消息供编程人员捕捉并处理。FD_ACCEPT 通知进程有客户方Socket请求连接，FD_READ通知进程本地Socket有东东可读，FD_CLOSE通知进程对方Socket已关闭。那么，BSD Socket 是不是真的相形见拙呢？非也！ 'cause cpu love unix so.BSD UNIX中有一系统调用芳名select()完全可以提供类似的消息驱动机制。cpu郑重宣布：WinSock的WSAAsyncSeclet()不过是此select()的fork版！bill也是fork出来的嘛，xixi.select()的机制中提供一fd_set的数据结构，实际上是一long类型的数组，每一个数组元素都能与一打开的文件句柄（不管是Socket句柄,还是其他文件或命名管道或设备句柄）建立联系，建立联系的工作由程序员完成，当调用select()时，由内核根据IO状态修改fd_set的内容，由此来通知执行了select()的进程哪一Socket或文件可读，下面具体解释：#include#include#includeint select(nfds, readfds, writefds, exceptfds, timeout)int nfds;fd_set *readfds, *writefds, *exceptfds;struct timeval *timeout;ndfs：select监视的文件句柄数，视进程中打开的文件数而定,一般设为呢要监视各文件中的最大文件号加一。readfds：select监视的可读文件句柄集合。writefds: select监视的可写文件句柄集合。exceptfds：select监视的异常文件句柄集合。timeout：本次select()的超时结束时间。（见/usr/sys/select.h，可精确至百万分之一秒！）当readfds或writefds中映象的文件可读或可写或超时，本次select()就结束返回。程序员利用一组系统提供的宏在select()结束时便可判断哪一文件可读或可写。对Socket编程特别有用的就是readfds。几只相关的宏解释如下：FD_ZERO(fd_set *fdset)：清空fdset与所有文件句柄的联系。FD_SET(int fd, fd_set *fdset)：建立文件句柄fd与fdset的联系。FD_CLR(int fd, fd_set *fdset)：清除文件句柄fd与fdset的联系。FD_ISSET(int fd, fdset *fdset)：检查fdset联系的文件句柄fd是否可读写，>0表示可读写。（关于fd_set及相关宏的定义见/usr/include/sys/types.h）这样，你的socket只需在有东东读的时候才读入，大致如下：...int sockfd;fd_setfdR;structtimeval timeout = ..;...for(;;) {FD_ZERO(&fdR);FD_SET(sockfd, &fdR);switch (select(sockfd + 1, &fdR, NULL, &timeout)) {case -1:error handled by u;case 0:timeout hanled by u;default:if (FD_ISSET(sockfd)) {now u read or recv something;/* if sockfd is father andserver socket, u can nowaccept() */}}}所以一个FD_ISSET(sockfd)就相当通知了sockfd可读。至于struct timeval在此的功能，请man select。不同的timeval设置使使select()表现出超时结束、无超时阻塞和轮询三种特性。由于timeval可精确至百万分之一秒，所以Windows的SetTimer()根本不算什么。你可以用select()做一个超级时钟。FD_ACCEPT的实现？依然如上，因为客户方socket请求连接时，会发送连接请求报文，此时select()当然会结束，FD_ISSET(sockfd)当然大于零，因为有报文可读嘛！至于这方面的应用，主要在于服务方的父Socket，你若不喜欢主动accept()，可改为如上机制来accept()。至于FD_CLOSE的实现及处理，颇费了一堆cpu处理时间，未完待续。--讨论关于利用select()检测对方Socket关闭的问题：仍然是本地Socket有东东可读，因为对方Socket关闭时，会发一个关闭连接通知报文，会马上被select()检测到的。关于TCP的连接（三次握手）和关闭（二次握手）机制，敬请参考有关TCP/IP的书籍。不知是什么原因，UNIX好象没有提供通知进程关于Socket或Pipe对方关闭的信号，也可能是cpu所知有限。总之，当对方关闭，一执行recv()或read()，马上回返回-1，此时全局变量errno的值是115，相应的sys_errlist[errno]为"Connect refused"（请参考/usr/include/sys/errno.h）。所以，在上篇的for(;;)...select()程序块中，当有东西可读时，一定要检查recv()或read()的返回值，返回-1时要作出关断本地Socket的处理，否则select()会一直认为有东西读，其结果曾几令cpu伤心欲断针脚。不信你可以试试：不检查recv()返回结果，且将收到的东东（实际没收到）写至标准输出...在有名管道的编程中也有类似问题出现。具体处理详见拙作：发布一个有用的Socket客户方原码。至于主动写Socket时对方突然关闭的处理则可以简单地捕捉信号SIGPIPE并作出相应关断本地Socket等等的处理。SIGPIPE的解释是：写入无读者方的管道。在此不作赘述，请详man signal。以上是cpu在作tcp/ip数据传输实验积累的经验，若有错漏，请狂炮击之。唉，昨天在hacker区被一帮孙子轰得差点儿没短路。ren cpu(奔腾的心) z80补充关于select在异步(非阻塞)connect中的应用,刚开始搞socket编程的时候我一直都用阻塞式的connect,非阻塞connect的问题是由于当时搞proxy scan而提出的呵呵通过在网上与网友们的交流及查找相关FAQ,总算知道了怎么解决这一问题.同样用select可以很好地解决这一问题.大致过程是这样的:1.将打开的socket设为非阻塞的,可以用fcntl(socket, F_SETFL, O_NDELAY)完成(有的系统用FNEDLAY也可).2.发connect调用,这时返回-1,但是errno被设为EINPROGRESS,意即connect仍旧在进行还没有完成.3.将打开的socket设进被监视的可写(注意不是可读)文件集合用select进行监视,如果可写,用getsockopt(socket, SOL_SOCKET, SO_ERROR, &error, sizeof(int));来得到error的值,如果为零,则connect成功.在许多unix版本的proxyscan程序你都可以看到类似的过程,另外在solaris精华 区->编程技巧中有一个通用的带超时参数的connect模块.
网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。 Socket的英文原义是“孔”或“插座”。作为BSD UNIX的进程通信机制，取后一种意思。通常也称作"套接字"，用于描述IP地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket正如其英文原意那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供220伏交流电， 有的提供110伏交流电，有的则提供有线电视节目。 客户软件将插头插到不同编号的插座，就可以得到不同的服务。

通俗的讲就是一个目标，句柄就是这个目标的名字，当然这个名字只是临时的，下次打开就换了一个名字，也就是数字句柄。 比如我要用拳头往前打，这就相当于前台。如果我要打一个人呢？那就先要找到这个人，找到的这个人就是句柄，对这个句柄操作。找到了，然后用拳头打。。。
句柄就是windows对象（窗口、进程、资源）的通用标识，记录的就是对象的内存首地址。 至于为啥有这个东西，因为API需要对windows各种语言通用，就发明了这么个东西。

临时编号

句柄是一个标识符，是拿来标识对象或者项目的。 如果想更透彻一点地认识句柄，我可以告诉大家，句柄类似指向指针的指针，仅仅是类似，通过句柄可以找到对应的数据，但是不是二级指针。我们知道，所谓指针是一种内存地址。应用程序启动后，组成这个程序的各对象是驻留在内存中的。简单地理解，似乎我们只要获知这个内存的首地址，就可以随时用这个地址访问对象了。如果您真的这样认为，那您可就大错特错了。我们知道，Windows是一个以虚拟内存为基础的操作系统。在这种系统环境下，Windows内存管理器经常在内存中来回移动对象，以此来满足各种应用程序的内存需要。对象被移动意味着它的地址变化了。如果地址总是如此变化，我们该到哪里去找那一个对象呢? 为了解决这个问题，Windows操作系统为全体应用程序腾出一些内存单元，用来专门登记各应用程序的对象在内存中的地址的变化，而前者的物理地址在系统运行期间是始终保持不变的。Windows内存管理器移动了对象在内存中的位置后，会把该对象新的地址及时地告知给对应的句柄进行更新。这样我们只要知道这个句柄，就可以间接地知道对象具体在内存中的哪个位置了。这个地址是在对象装载（Load）时由系统分配给的，当对象卸载时（Unload）又释放给系统。

第一种解释：句柄是一种特殊的智能指针 。当一个应用程序要引用其他系统（如数据库、操作系统）所管理的内存块或对象时，就要使用句柄。 第二种解释：整个Windows编程的基础。一个句柄是指使用的一个唯一的整数值，即一个4字节(64位程序中为8字节)长的数值，来标识应用程序中的不同对象和同类中的不同的实例，诸如，一个窗口，按钮，图标，滚动条，输出设备，控件或者文件等。应用程序能够通过句柄访问相应的对象的信息，但是句柄不是指针，程序不能利用句柄来直接阅读文件中的信息。如果句柄不在I/O文件中，它是毫无用处的。 句柄是Windows用来标志应用程序中建立的或是使用的唯一整数，Windows大量使用了句柄来标识对象。

我也不知道····只好复制一份···共同学习~~ 要写网络程序就必须用Socket，这是程序员都知道的。而且，面试的时候，我们也会问对方会不会Socket编程？一般来说，很多人都会说，Socket编程基本就是listen，accept以及send，write等几个基本的操作。是的，就跟常见的文件操作一样，只要写过就一定知道。对于网络编程，我们也言必称TCP/IP，似乎其它网络协议已经不存在了。对于TCP/IP，我们还知道TCP和UDP，前者可以保证数据的正确和可靠性，后者则允许数据丢失。最后，我们还知道，在建立连接前，必须知道对方的IP地址和端口号。除此，普通的程序员就不会知道太多了，很多时候这些知识已经够用了。最多，写服务程序的时候，会使用多线程来处理并发访问。我们还知道如下几个事实：1。一个指定的端口号不能被多个程序共用。比如，如果IIS占用了80端口，那么Apache就不能也用80端口了。2。很多防火墙只允许特定目标端口的数据包通过。3。服务程序在listen某个端口并accept某个连接请求后，会生成一个新的socket来对该请求进行处理。于是，一个困惑了我很久的问题就产生了。如果一个socket创建后并与80端口绑定后，是否就意味着该socket占用了80端口呢？如果是这样的，那么当其accept一个请求后，生成的新的socket到底使用的是什么端口呢（我一直以为系统会默认给其分配一个空闲的端口号）？如果是一个空闲的端口，那一定不是80端口了，于是以后的TCP数据包的目标端口就不是80了--防火墙一定会组织其通过的！实际上，我们可以看到，防火墙并没有阻止这样的连接，而且这是最常见的连接请求和处理方式。我的不解就是，为什么防火墙没有阻止这样的连接？它是如何判定那条连接是因为connet80端口而生成的？是不是TCP数据包里有什么特别的标志？或者防火墙记住了什么东西？后来，我又仔细研读了TCP/IP的协议栈的原理，对很多概念有了更深刻的认识。比如，在TCP和UDP同属于传输层，共同架设在IP层（网络层）之上。而IP层主要负责的是在节点之间（End to End）的数据包传送，这里的节点是一台网络设备，比如计算机。因为IP层只负责把数据送到节点，而不能区分上面的不同应用，所以TCP和UDP协议在其基础上加入了端口的信息，端口于是标识的是一个节点上的一个应用。除了增加端口信息，UPD协议基本就没有对IP层的数据进行任何的处理了。而TCP协议还加入了更加复杂的传输控制，比如滑动的数据发送窗口（Slice Window），以及接收确认和重发机制，以达到数据的可靠传送。不管应用层看到的是怎样一个稳定的TCP数据流，下面传送的都是一个个的IP数据包，需要由TCP协议来进行数据重组。所以，我有理由怀疑，防火墙并没有足够的信息判断TCP数据包的更多信息，除了IP地址和端口号。而且，我们也看到，所谓的端口，是为了区分不同的应用的，以在不同的IP包来到的时候能够正确转发。TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。就像操作系统会提供标准的编程接口，比如Win32编程接口一样，TCP/IP也必须对外提供编程接口，这就是Socket编程接口--原来是这么回事啊！在Socket编程接口里，设计者提出了一个很重要的概念，那就是socket。这个socket跟文件句柄很相似，实际上在BSD系统里就是跟文件句柄一样存放在一样的进程句柄表里。这个socket其实是一个序号，表示其在句柄表中的位置。这一点，我们已经见过很多了，比如文件句柄，窗口句柄等等。这些句柄，其实是代表了系统中的某些特定的对象，用于在各种函数中作为参数传入，以对特定的对象进行操作--这其实是C语言的问题，在C++语言里，这个句柄其实就是this指针，实际就是对象指针啦。现在我们知道，socket跟TCP/IP并没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以，socket的出现只是可以更方便的使用TCP/IP协议栈而已，其对TCP/IP进行了抽象，形成了几个最基本的函数接口。比如create，listen，accept，connect，read和write等等。现在我们明白，如果一个程序创建了一个socket，并让其监听80端口，其实是向TCP/IP协议栈声明了其对80端口的占有。以后，所有目标是80端口的TCP数据包都会转发给该程序（这里的程序，因为使用的是Socket编程接口，所以首先由Socket层来处理）。所谓accept函数，其实抽象的是TCP的连接建立过程。accept函数返回的新socket其实指代的是本次创建的连接，而一个连接是包括两部分信息的，一个是源IP和源端口，另一个是宿IP和宿端口。所以，accept可以产生多个不同的socket，而这些socket里包含的宿IP和宿端口是不变的，变化的只是源IP和源端口。这样的话，这些socket宿端口就可以都是80，而Socket层还是能根据源/宿对来准确地分辨出IP包和socket的归属关系，从而完成对TCP/IP协议的操作封装！而同时，放火墙的对IP包的处理规则也是清晰明了，不存在前面设想的种种复杂的情形。明白socket只是对TCP/IP协议栈操作的抽象，而不是简单的映射关系，这很重要！

句柄是一种不透明指针，通常用来对用户隐藏数据结构实现，这样可以防止用户任意修改数据对象的内容，所有操作必须通过相应API进行，这是一种OOP中常见的概念，即信息隐藏（封装），好处是实现者可以随意修改数据结构实现也不用影响客户代码。比如Win32上有个叫HANDLE的类型，其定义成类型void*这种不透明指针，用户无从知道具体对应的结构体。 就像vbtrazz所说，也可以是资源编号，任何可以唯一标识一个对象的东西都可以说是句柄，好处上面已经提及。
句柄就是一个整型数据，这个整型数据对应了一个数据结构体，可能是个结构也可能是个类。 当需要操作一些比较复杂的数据时，我们往往会用到句柄，句柄使我们可以省略掉一些复杂的数据访问语句。当调用相关函数时，需要提供相应有效句柄参数，函数会自动用这个句柄来调用其中对应的数据和函数完成相应功能。
这个是没有一定的， 一般可以理解成间接的指针， 或者资源的编号。 总之句柄是具体系统提供的一个机制， 它也必须要提供相应的处理函数， 而它在系统里具体是代表个什么意义是不要深究的
楼上学的是什么句柄啊 所谓句柄实际上是一个数据，是一个long(整长型)的数据。句柄是wondows用来标识被应用程序所建立或使用的对象的唯一整数，windows使用各种各样的句柄标识诸如应用程序实例，窗口，控制，位图，gdi对象等等。windows句柄有点象c语言中的文件句柄。从上面的定义中的我们可以看到，句柄是一个标识符，是拿来标识对象或者项目的，它就象我们的姓名一样，每个人都会有一个，不同的人的姓名不一样，但是，也可能有一个名字和你一样的人。从数据类型上来看它只是一个16位的无符号整数。应用程序几乎总是通过调用一个windows函数来获得一个句柄，之后其他的windows函数就可以使用该句柄，以引用相应的对象。如果想更透彻一点地认识句柄，我可以告诉大家，句柄是一种指向指针的指针。我们知道，所谓指针是一种内存地址。应用程序启动后，组成这个程序的各对象是住留在内存的。如果简单地理解，似乎我们只要获知这个内存的首地址，那么就可以随时用这个地址访问对象。但是，如果您真的这样认为，那么您就大错特错了。我们知道，windows是一个以虚拟内存为基础的操作系统。在这种系统环境下，windows内存管理器经常在内存中来回移动对象，依此来满足各种应用程序的内存需要。对象被移动意味着它的地址变化了。如果地址总是如此变化，我们该到哪里去找该对象呢?为了解决这个问题，windows操作系统为各应用程序腾出一些内存储地址，用来专门登记各应用对象在内存中的地址变化，而这个地址(存储单元的位置)本身是不变的。windows内存管理器在移动对象在内存中的位置后，把对象新的地址告知这个句柄地址来保存。这样我们只需记住这个句柄地址就可以间接地知道对象具体在内存中的哪个位置。这个地址是在对象装载(load)时由系统分配给的，当系统卸载时(unload)又释放给系统。句柄地址(稳定)→记载着对象在内存中的地址————→对象在内存中的地址(不稳定)→实际对象本质：windows程序中并不是用物理地址来标识一个内存块，文件，任务或动态装入模块的，相反的，windowsapi给这些项目分配确定的句柄，并将句柄返回给应用程序，然后通过句柄来进行操作。 但是必须注意的是程序每次从新启动，系统不能保证分配给这个程序的句柄还是原来的那个句柄，而且绝大多数情况的确不一样的。假如我们把进入电影院看电影看成是一个应用程序的启动运行，那么系统给应用程序分配的句柄总是不一样，这和每次电影院售给我们的门票总是不同的一个座位是一样的道理。