CSDN论坛 > VC/MFC > 基础类

严重关注: WIN2K下的SOCKET编程问题, 有关send()和closesocket()! [问题点数:0分]

Bbs1
本版专家分:0
结帖率 100%
CSDN今日推荐
匿名用户不能发表回复!
其他相关推荐
windows下socket编程:区分shutdown()及closesocket()
以下描述主要是针对windows平台下的TCP socket而言。 首先需要区分一下关闭socket和关闭TCP连接的区别,关闭TCP连接是指TCP协议层的东西,就是两个TCP端之间交换了一些协议包(FIN,RST等),具体的交换过程可以看TCP协议,这里不详细描述了。而关闭socket是指关闭用户应用程序中的socket句柄,释放相关资源。但是当用户关闭socket句柄时会隐含的触发TCP连接
socket遇到错误直接退出原因和解决办法
原因:socket遇到错误时,默认将错误信息交给系统处理,而系统的处理办法一般是直接关闭整个应用,所以就会出现遇到错误程序直接关闭,比如客户端关闭,服务器还在给客户端发信息,就会出现发送失败,导致服务器也直接关闭的现象解决办法:把错误交给自己定义的函数处理 先定义一个函数void Perr(int signum) { if(signum==SIGPIPE) { fpri
关闭套接字closesocket()
本文来自百度百科   此函数关闭套接字s,并释放分配给该套接字的资源,以后对s 的引用都将产生错误WSAENOTSOCK。如果s涉及一个打开的TCP连接,该连接被释放。 中文名 closesocket() 注    释 本函数关闭一个套接口 类    型 函数
(转载) socket:10038错误{winSock的一个bug:当closesocket多次错误使用时会导致问题}
这几天想在一个开源的代码上进行修改,以期研发出一个产品出来。       程序原来是单线程网络程序,需要修改为多线程,修改之后,总是出问题,辅助线程中的recv函数总是运行一阵子之后收到长度为-1的数据报,导致程序运行不正确甚至崩溃。        由于是多线程,只好打日志进行调试,发现一个奇怪的问题。在A线程与B线程中,均使用了socket这个函数来产生socket,竟然会产生两个相同返回值的s
linux网络编程之socket(十):shutdown 与 close 函数 的区别
假设server和client 已经建立了连接,server调用了close, 发送FIN 段给client(其实不一定会发送FIN段,后面再说),此时server不能再通过 socket发送和接收数据,此时client调用read,如果接收到FIN 段会返回0,但client此时还是可以write 给server的,write调用只负责把数据交给TCP 发送缓冲区就可以成功返回了,所以不会出
socket中的close和shutdown区别
很明显这个两个函数是有差别的。close关闭本进程的socket id,但链接还是开着的。怎么理解?我们知道socket描述符是对内核中socket对象的引用。而close操作的正式socket描述符,可以理解为断开了当前进程和内核中socket对象的关系。但是其他进程同样可以和这个socket对象建立关系。当然也就是说连接是开着的(因为其他进程可以通过socket读写数据)shutdown破坏了s
VC++ Scoket编程小结
#include //可以工程向导中设置支持scoket #pragma comment(lib, "ws2_32.lib") //也可以通过属性选项设置 socket、bind、connect、accept、listen、send、recv、closesocket、htonl、ntohl、inet_addr、inet_ntoa、getsockname、getpeerna
socket返回SOCKET_ERROR但是errno为0
Because you are working with Windows sockets, you will need to use the WSAGetLastError() function to check the error code.
使用socket函数的一些常见错误
原文地址:使用socket函数的一些常见错误1.socketSOCKET socket( int af, int type, int protocol ); af:常为AF_INET 使用AF_ISO等其他地址族标识,而非AF_INET。 返回:-1。 错误:10047(使用了与请求的协议不兼容的地址) type,通常为SOCK_STREAM或SOCK_DGRAM 头文件中定义的只有如下几种
linux下close 掉socket 之后 阻塞的recv 不会立即返回
在开发的一个基于rtmp聊天的程序时发现了一个很奇怪的现象。 在windows下当我们执行 closesocket 的操作之后,阻塞的 recv 会立即返回 -1 。 而在linux 下 当我们执行 close 操作之后 阻塞的recv 会出现不能立即返回的现象。后来在网上一搜发现很多遇到类似这种现象的情况,大致意思应该是 当socket 被动被close 的时候 进入了 “CLOSE_WA
关闭