linux关闭socket,Linux卸载软件

这篇文章给大家聊聊关于linux关闭socket,以及Linux卸载软件对应的知识点,希望对各位有所帮助,不要忘了收藏本站哦。

Linux C中的Socket,shutdown函数和close函数有什么不同

假设server和client已经建立了连接,server调用了close,发送FIN段给client(其实不一定会发送FIN段,后面再说),此时server不能再通过socket发送和接收数据,此时client调用read,如果接收到FIN段会返回0,但client此时还是可以write给server的,write调用只负责把数据交给TCP发送缓冲区就可以成功返回了,所以不会出错,而server收到数据后应答一个RST段,表示服务器已经不能接收数据,连接重置,client收到RST段后无法立刻通知应用层,只把这个状态保存在TCP协议层。如果client再次调用write发数据给server,由于TCP协议层已经处于RST状态了,因此不会将数据发出,而是发一个SIGPIPE信号给应用层,SIGPIPE信号的缺省处理动作是终止程序。有时候代码中需要连续多次调用write,可能还来不及调用read得知对方已关闭了连接就被SIGPIPE信号终止掉了,这就需要在初始化时调用sigaction处理SIGPIPE信号,对于这个信号的处理我们通常忽略即可,signal(SIGPIPE, SIG_IGN);如果SIGPIPE信号没有导致进程异常退出,write返回-1并且errno为EPIPE。#include intclose(int fd);close关闭了自身数据传输的两个方向。#include intshutdown(int sockfd, int how);shutdown可以选择关闭某个方向或者同时关闭两个方向,shutdownhow= 1 or how= 2(SHUT_WR or SHUT_RDWR),可以保证对等方接收到一个EOF字符(即发送了一个FIN段),而不管其他进程是否已经打开了这个套接字。而close不能保证,只有当某个sockfd的引用计数为0,close才会发送FIN段,否则只是将引用计数减1而已。也就是说只有当所有进程(可能fork多个子进程都打开了这个套接字)都关闭了这个套接字,close才会发送FIN段。所以说,如果是调用shutdown how= 1,则意味着往一个已经接收FIN的套接字中写是允许的,接收到FIN段仅代表对方不再发送数据,但对方还是可以读取数据的,可以让对方可以继续读取缓冲区剩余的数据。下面使用shutdown修改客户端程序,在前面讲过的使用select函数修改后的客户端程序基础上,修改很小一部分:C++ Codeif(FD_ISSET(fd_stdin,&rset)){if(fgets(sendbuf, sizeof(sendbuf), stdin)== NULL){stdineof= 1;//表示已经输入完毕/*关闭sock的写端,还能够接收数据,在sock的缓冲区末尾添加一个FIN段*/shutdown(sock, SHUT_WR);}else{writen(sock, sendbuf, strlen(sendbuf));memset(sendbuf, 0, sizeof(sendbuf));}}为了测试我们想要的效果,需要在select函数修改后的服务器端程序的 134行代码之后,即writen之前 sleep(4);目的是接收到客户端数据后不马上回射回去,睡眠4s后在客户端已经关闭连接的情况下再发送数据。先运行服务器端程序,再运行客户端程序,在客户端标准输入,迅速敲入两行:AAAAA

BBBBB

然后按下ctrl+d即fgets会返回NULL,然后调用shutdown关闭写端,虽然服务器端延时才发送数据,此时客户端写端已经关闭,但还是可以读取到回射回来的数据,服务器端最后得到一个FIN段,read返回0,打印输出 client close,并且close(conn);而客户端在读取服务端回射回来的两次数据后,再次read也返回0,故打印 server connectclose,break退出循环,进程顺利退出。从下面的输出还可以看出,因为延时的关系,所以不像以前那样发射一行就回射一行。simba@ubuntu:~/Documents/code/linux_programming/UNP/socket$./echoser_selectrecv connect ip=127.0.0.1 port=54010fdsgfgdgfedgclient close...........................simba@ubuntu:~/Documents/code/linux_programming/UNP/socket$./echocli_select_shutdownlocal ip=127.0.0.1 port=54010fdsgfgdgfedgfdsgfgdgfedg1gfedgserver connect close如果我们将客户端程序中的shutdown改成了 close,那么当延时后服务器端发送数据给客户端时,客户端的读端和写端都已经关闭,第一次发AAAAA会返回一个RST段,根据本文前面所说,再次发BBBBB直接产生SIGPIPE信号,默认会终止进程,但因为我们已经设置了忽略SIGPIPE信号,所以服务器端进程不会被终止,但客户端也会出错,因为回到while循环开头,select阻塞等待时发现套接字的读端已经关闭,所以不能再关心可读事件了,select会返回-1,错误码是 EBADF: Bad File Descriptor。Linux C中的Socket,shutdown函数和close函数有什么不同

linux python socket怎么去除

原因是server端关掉了tcp连接,给client发送FIN信号,client的tcp层回了ACK,然后它的socket状态就处于close_wait状态。

实验:

Python中,socket在send之前处于close_wait状态,那么该send不会报错,并且执行完之后socket就closed了。再继续调用send就会报错。

推理:

说明python的socket.send在发送数据之前会检查socket的状态,如果处于close_wait,就执行close(socket)(应用层感觉不到哦),然后正常退出。所以再次send时,会抛出异常。

为什么会一直处close_wait状态?

当socket处于close_wait时,必须由应用层调用close(socket),发送FIN给server端才能变为LAST_ACK,接收到server端回应的ACK后,才变为CLOSED。如果应用层不调用close(),那么socket会一直处于close_wait。[1]

如果我在python中不断循环去调用socket.sendall(),那么在socket变为close_wait后,通过socket.sendall()也会关闭socket,为什么它还是一直处在close_wait状态呢?

原因在于当sendall(data)的data比较大,在data被发送一半时,连接被server端断掉了。那么sendall(data)会一直卡在那,也就不会执行到sendall的开始处,去判断socket状态,确定是否关闭socket了。

简单而言,就是socket在变为close_wait之后,根本没有调用sendall()去关闭socket。

linuxsocket阻塞如何退出

设置套接字为非阻塞模式。

1、通过设置套接字的属性,把其从阻塞模式改为非阻塞模式,即使没有数据到来或者连接建立,程序也不会一直等待,而是立刻返回。

2、超时机制:在代码中设置超时机制,即如果套接字在指定时间内依然处于阻塞状态,则退出程序。

3、信号处理:使用信号处理机制,在另一个线程中发送一个指定的信号,如SIGINT信号,当程序接收到该信号时,可以退出当前的阻塞状态。

阅读剩余
THE END