转载自:http://www.cnblogs.com/wainiwann/p/3942203.html 在开发的一个基于rtmp聊天的程序时发现了一个很奇怪的现象. 在windows下当我们执行 closesocket的操作之后,阻塞的 recv会立即返回 -1 . 而在linux下当我们执行close操作之后阻塞的recv会出现不能立即返回的现象.后来在网上一搜发现很多遇到类似这种现象的情况,大致意思应该是 当socket被动被close的时候进入了 "CLOSE_WAIT(被动关闭一方)&q

引子 前段时间我们的服务由于一台交换机网络出现故障,导致数据库连接不上,但是在数据库的连接超时参数设置不合理,connect timeout设置的过长,导致接口耗时增加.DB连接超时后线程未正常结束,上游请求又持续进来,最终耗光了Java线程,JVM进入持续GC状态,无法恢复,直到手工重启才恢复服务. 于是在服务的保护方面新增了两个措施,第一,调小服务端workThread的最大线程数.第二,在Server端设置Accept后Socket的readTimeout时间,当Socket调用read方

再学 socket 之非阻塞 Server 本文是基于 python2.7 实现,运行于 Mac 系统下 本篇文章是上一篇初探 socket 的续集, 上一篇文章介绍了:如何建立起一个基本的 socket 连接.TCP 和 UDP 的概念.socket 常用参数和方法 Socket 是用来通信.传输数据的对象,上一篇已经研究了如果进行基本的通行和传输数据.因为,在这个互 联网爆发的时代,做为 Server 的 socket 要同时接收很多的请求. 通过阅读:地址,强烈推荐阅读原文. 整理了下面的

转自:https://blog.csdn.net/lunweiwangxi3/article/details/50468593 ue4自带的Fsocket用起来依旧不是那么的顺手,感觉超出了我的理解范围了.另外我也不想让我近一个礼拜研究的C++ Socket无用武之地,毅然决然的决定使用自己的C++通讯库.再美再豪华的别墅真不如自己亲手搭建的草庐来的舒畅.这就好比我表弟,要花200块钱玩一个游戏,我说,我有一个1000巅峰的大神号,我不玩了,送你吧,你不要买了.他说:不!我就要自己的号! 他梦幻

声明:该博文以socket中,关闭输出流为例进行说明. 为了方便讲解,我们把DataOutputstream dout = new DataOutputStream(new BufferedOutputStream(mySocket.getOutputStream()));中的dout做为Socket输出流的代言.同样的,din是输入流的代言. 可以造成dout被关闭的操作有: 1.调用dout.close();或din.close();因为使用这种流关闭,会造成socket被关闭,所以输入输出

文章出自:http://blog.csdn.net/VCSockets/ 1.TCP中的阻塞Socket和非阻塞Socket 阻塞与非阻塞是对一个文件描述符指定的文件或设备的两种工作方式. 阻塞的意思是指,当试图对该文件描述符进行读写时,如果当时没有东西可读或者暂时不可写,程序就进入等待状态,直到有东西可读或者可写为止. 非阻塞的意思是,当没有东西可读或者不可写时,读写函数就马上返回,而不会等待. !!!阻塞模式 在阻塞模式的套接字上,调用任何一个Windows Sockets API都会耗费不

import socket # 创建socket client = socket.socket() # 将原来阻塞的位置变成非阻塞(报错) client.setblocking(False) # 百度创建连接: 阻塞 try: # 执行了但报错了 client.connect(('www.baidu.com',80)) except BlockingIOError as e: pass # 检测到已经连接成功 # 问百度我要什么? client.sendall(b'GET /s?wd=alex

socket缓冲区 每个 socket 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区. write()/send() 并不立即向网络中传输数据,而是先将数据写入缓冲区中,再由TCP协议将数据从缓冲区发送到目标机器.一旦将数据写入到缓冲区,函数就可以成功返回,不管它们有没有到达目标机器,也不管它们何时被发送到网络,这些都是TCP协议负责的事情. TCP协议独立于 write()/send() 函数,数据有可能刚被写入缓冲区就发送到网络,也可能在缓冲区中不断积压,多次写入的数据被一次性发送到

select 函数 int select(int maxfdp,fd_set *readfds,fd_set *writefds,fd_set *errorfds,struct timeval*timeout); fd_set * readfds 需要监视变化的文件描述符 只要有一个文件可读就返回>0 没有文件可读 超出timeout时间,返回=0 发生错误返回负值 传入NULL表示不关心任何文件 fd_set * readfds 需要监视变化的文件描述符 只要有一个文件可写就返回>0 没有文

在上一篇文章 <socket编程——一个简单的例子> http://blog.csdn.net/wind19/archive/2011/01/21/6156339.aspx 中写了一个简单的tcp socket通信程序,可以进行数据的交互,但有一个问题是这个程序是阻塞的,任何socket函数都要等返回后才能进行下一步动作,如果recv一直没有数据,那么就一直不会返回,整个进程就阻塞在那.所以我们要进行改造一下,让程序不再阻塞在那,而是在有数据到来的时候读一下数据,有数据要写的时候发送一下数据.

一.socket缓冲区 每个 socket 被创建后,都会分配两个缓冲区,输入缓冲区和输出缓冲区. 以下用write()/send()表示写数据/发送数据,read()/recv() 表示读数据/接收数据进行说明. write()/send()并不立即向网络中传输数据,而是先将数据写入缓冲区中,再由TCP协议将数据从缓冲区发送到目标机器.一旦将数据写入到缓冲区,函数就可以成功返回,不管它们有没有到达目标机器,也不管它们何时被发送到网络,这些都是TCP协议负责的事情. TCP协议独立于 write

以Socket发送数据为例: 发送数据时候要声明:DataOutputStream os = new DataOutputStream(socket.getOutputStream()); 最近开发遇到的为题是我要向服务端发送图片,如果os.close()的话服务器可以收到图片但是我客户端的socket会受影响关闭.如果不用os.close()的话,服务器接收图片会有影响,查资料说调用socket.shutdownOutputStream();可以关闭输出流,而且不会影响socket发送数据.

同步I/O模型的弊端===>每一个线程的创建都会消耗服务端内存,当大量请求进来,会耗尽内存,导致服务宕机 伪异步I/O的弊端分析===>当对Socket的输入流进行读取操作的时候,它会一直阻塞下去,知道发生如下三件事情(1)有数据可读(2)可用数据已经读取完毕(3)发生空指针或者I/O异常===>这意味着当对方发送请求或应答消息比较缓慢,或者网络传输比较慢时候,读取输入流的一方的通信线程将被长时间阻塞.在阻塞期间,其他接入的消息只能在消息队列中排队.===>伪异步I/O实际上仅仅只

一.fcntl 用以下方法将socket设置成为非阻塞方式 int  flags = fcntl(socket,F_GETFL,0); fcntl(socket,F_SETFL,flags|O_NONBLOCK); 将非阻塞的设置回阻塞可以用 int  flags = fcntl(socket,F_GETFL,0); fcntl(socket,F_SETFL,flags&~O_NONBLOCK); -------------------------------------------------

通过两种方式可以关闭一个socket:close和shutdown.直接调用close关闭socket存在以下两个问题: 1. close只是将socket 描述字的访问计数减1,仅当描述字的访问计数为0时,才真正的关闭socket. 2.close终止了数据传输的两个方向:读与写.tcp管道是全双工的,有时候我们仅仅是想通知另一端我们已经完成了数据的发送,但还想继续接收另一端发送过来的数据,在这种情况下调用close关闭socket是不合适的. shutdown可以解决上面关于close的两个

通常,使用关闭输出流来表示输出已经结束.但在进行网络通信时则不能这样做.因为我们关闭输出流时,该输出流对应的Socket也将随之关闭,这样程序将无法再从该socket中读取数据. 为了应付这种情况,socket提供了两个半关闭的方法用来只关闭socket的输入流或者输出流,用以表示输出数据已经发送完成.方法详情: shutdownInput():关闭该socket的输入流,程序还可以通过该socket的输出流输出数据: shutdownOutput():关闭该socket的输出流,程序还可以通过

在使用tcp的connect调用时,默认是使用阻塞方式,当服务器当前不可用时,connect会等待(内部在重试?)直到超时时间到达,而这个超时时间是系统内核规定的,不能使用setSocketOpt来设置. 在碰到服务器不可用,上层逻辑进行重试时,如果超时时间过长,会产生卡死的感觉,用户体验也不佳,所以需要控制connect的超时时间. 参考网络上的资料,这里使用select.实现方式是:将socket设置为非阻塞方式,使用select来轮询socket,在select里指定超时时间,根据sock

转自:https://blog.csdn.net/u012525096/article/details/76924627 今天写安卓向服务器发送图片,过程为:客户端发送数据->服务器接收.处理数据->服务器返回处理信息->客户端接收数据并显示.安卓客户端中,发送数据(out.write)后,调用out.close(),当接收数据a=in.read(data)时,报错. 错误代码:socket recvfrom failed: EBADF (Bad file descriptor) 首先尝

前置知识:socket非阻塞函数(socket.setblocking(False)),简单多线程编程 代码示例: 1. 单线程非阻塞版本: 服务端: #!/usr/bin/env python # encoding: utf-8 import socket import os import sys import time import traceback reload(sys) sys.setdefaultencoding("utf-8") def socketInit(HOST,P

1. 概述:简单的基于Windows API的socket点对点聊天程序,为了方便初学者,本文代码均采用阻塞原理编写. 2. 代码样例 Server.cpp(服务端) #include <cstdio> #include <cstdlib> #include <iostream> #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <Winsock2.h> using namespa

MSL就是maximum segment lifetime(最大分节生命期),这是一个IP数据包能在互联网上生存的最长时间,超过这个时间将在网络中消失 TIME_WAIT两点原因: 1.TCP分节可能由于路由器异常而“迷途”,在迷途期间,TCP发送端可能因确认超时而重发这个分节,迷途的分节在路由器修复后也会被送到最终目的地,这个 原来的迷途分节就称为lost duplicate.在关闭一个TCP连接后,马上又重新建立起一个相同的IP地址和端口之间的TCP连接,后一个连接被称为前一个连接的化身 (