网站js特效悬浮框网络推广团队哪家好
目录
V1_Echo_Server
V2_Echo_Server多进程版本
V3_Echo_Server多线程版本
V3-1_多线程远程命令执行
V4_Echo_Server线程池版本
V1_Echo_Server
TcpServer的上层调用如下，和UdpServer几乎一样：
而在InitServer中，大部分也和UDP那里一样，不同的是使用socket时第二个参数是SOCK_STREAM。
除了创建socket和bind外，还有第三步，因为tcp是面向连接的，tcp需要未来不断地能够做到获取连接，需要将server套接字设为listen状态，以便随时等待被获取连接，
其中backlog一般设为较小的数字，比如4、8等。
此时，server处于listen状态，等待别人随时来连接自己，listen就比如饭馆老板一天随时等待客人来吃饭。然后，我们可以添加一个_isrunning的成员变量，以表明服务器的运行状态，初始化为false。
在server处于listen状态后，因为tcp是需要连接的，需要使用accept函数来获取连接：
其中，第一个参数是server的套接字，后两个参数是用来得到是谁来连接server。关键在于accept的返回值：
我们看到accept的返回值竟然是一个文件描述符，这就让我们有点蒙圈了。因为在之前写udp代码时，只有一个文件描述符，那么此时我们难免有这样两个疑问：
- return fd是什么？
- return fd 和 _sockfd的关系
我们来将一个小故事，比如你和你的朋友去杭州西湖玩，在那里附近有很多饭馆，有一家叫西湖鱼庄，这家店雇了张三在店外面拉客，正好你在饭点碰到这家饭馆，就被拉了进去吃饭，张三带着你们进了饭店门口，然后张三喊来客人了，出来个人招呼客人，然后李四就出来招呼你们了。然后，张三又去店外面继续拉客，过了不久，张三又拉来了几个客人，到了店里喊又来客人了，出来个人招呼，此时王五出来招呼这几个客人，张三又跑出去继续拉客。在这个过程中，张三不给客人提供服务，只负责拉客。这个西湖鱼庄就是服务器，一个个客户就是一个个连接，而张三就是类成员_sockfd，李四、王五就相当于accept的返回值return fd，这个返回值来给连接提供服务，_sockfd就是用来协助accept获取新连接。把这个只负责获取连接的_sockfd叫做listensockfd（监听套接字）。
把成员变量改为_listensockfd。
如果张三拉客失败，也就是accept的返回值为0，那会怎么样呢？张三当然会继续拉客。
在提供服务时，由于udp是面向数据报，udp只能用recvfrom和sendto这样和网络强相关的接口，而tcp是面向字节流。之前我们学过C/C++的文件流以及管道的字节流，这些都是“流”，实际上它们都是一个东西，Linux下一切皆文件，所以网络、管道等都是文件，所以只要符合相同的流的特性，tcp这里的字节流的读取就相当于文件读取，也就是可以使用read/write进行读取。当使用read进行读取时，表明读取客户端结束（文件中表示读到文件结尾，这点有区别）。
在客户端这里，也是首先创建套接字，然后不需要显式bind，但是一定要有自己的IP和port，所以需要隐式bind，OS会用自己的IP和随机端口号去bind sockfd。客户端也不需要监听，没人回来连接客户端。server在等连接，所以客户端需要发起连接，使用connect调用，
那什么时候进行自动bind呢？在创建连接成功时就会bind！client的代码如下：
int main(int argc, char* argv[])
{if(argc != 3){std::cerr << "Usage: " << argv[0] << "server_ip server_port" << std::endl;exit(0);}std::string server_ip = argv[1];uint16_t server_port = std::stoi(argv[2]);//1.创建socketint sockfd = ::socket(AF_INET, SOCK_STREAM, 0);if(sockfd < 0){std::cerr << "create socket error" << std::endl;exit(1);}//2.connectstruct sockaddr_in server;memset(&server, 0 , sizeof(server));server.sin_family = AF_INET;server.sin_port = htons(server_port);::inet_pton(AF_INET, server_ip.c_str(), &server.sin_addr.s_addr);int n = ::connect(sockfd, (struct sockaddr*)&server, sizeof(server));if(n < 0){std::cerr << "connect socket error\n" << std::endl;exit(2);}while(true){std::string message;std::cout << "Enter# ";std::getline(std::cin, message);write(sockfd, message.c_str(), message.size());char echo_buffer[1024];int n = ::read(sockfd, echo_buffer, sizeof(echo_buffer)-1);if(n > 0){echo_buffer[n] = 0;std::cout << echo_buffer << std::endl;}else{break;}}::close(sockfd);return 0;
}我们编译运行这份代码，当启动第一个客户端时，发现可以正常echo：
然后我们再启动第二个客户端，发现服务器没有和第二个客户端建立连接，也没有echo，
只有把第一个客户端退出后，服务器才能和第二个客户端建立连接，服务器才能echo第二个客户端，
因此，我们发现这版客户端代码没有并发处理能力，一次只能处理一个客户端，这时因为主线程一直在Service内部在运行：
所以，为了解决以上服务器端不能并发处理的问题，
V2_Echo_Server多进程版本
因此，我们在处理Service时，通过创建子进程来处理：
父子进程都要有独立的文件描述符表，而子进程的文件描述符表是从父进程那里拷贝来的，注定了父子进程指向了同样的文件，所以子进程肯定能看见创建的创建的sockfd（代码是共享的，数据以写时拷贝的方式各自私有一份），也就是说，父进程打开了多少个文件，子进程可以看到并且能访问。父进程创建的listensockfd是3文件描述符，子进程创建的sockfd是4号文件描述符，子进程从父进程拷贝了文件描述符表，所以和父进程指向同一个文件。因为子进程不关心3，只关心4，这里的建议是让子进程关闭listensockfd，只保留sockfd。同时要求父进程关闭sockfd，只保留listensockfd，这里是要求，如果父进程不关sockfd，相当于4号文件描述符一直被占用，如果再有客户端来连接服务器，只能使用5号文件描述符来处理，导致父进程的文件描述符一直在被打开而从来没有被关闭，文件描述符的本质就是数组的下标，数组下标肯定是有限个，这就导致了文件描述符泄漏的问题。
所以，我们期望的是父进程把自己该做的做完，然后去回到accept，继续等待被连接。而子进程去执行if(id ==0)内部的代码，这样就能做到服务器采用多进程的方式并发处理连接，
可是，父进程在waitpid时采用的是0（阻塞式等待），所以我们刚才想的理想过程不会发生，子进程在处理任务期间，父进程会阻塞等待，这不是还是一次只能处理一个连接吗？！那怎么解决呢？我们在学习信号的时候，子进程在退出时，会向父进程发送SIGCHID信号，如果对SIGCHID进程ingore，那父进程就不需要等子进程退出了，只负责连接就行了，这种方式是可行的也是最推荐的。
此外，我们还可以这样做：
在子进程中再创建子进程，也就是孙子进程。if(fork() > 0)exit(0)让子进程直接退了，直接留下孙子进程。子进程返回了，父进程就能等待成功然后返回了。当孙子进程处理完后，就会变成孤儿进程，被系统领养，就不用再关心这个孙子进程了。但是这不是最好方案，最好方案就是上面那种。
V3_Echo_Server多线程版本
创建新线程，主线程会等待新线程，这还是串行运行，不能实现并发访问。为此，我们想到之前学过线程分离，不再让主线程等待新线程，而是让新线程分离，
那用于执行任务的文件描述符sockfd怎么交给新线程呢？我们知道，新线程和主线程是共享同一张文件描述符表的，这里绝对不能让主线程和新线程关闭自己不用的套接字fd，也不需要了。我们把Execute函数设置为了static属性，不能访问类内方法，不能访问类内的Service方法，为此，我们创建一个内部类ThreadData：
V3-1_多线程远程命令执行
由远程发过来命令行字符串，server对命令行字符串进行执行，把执行结果返回给远程。建立Command.hpp头文件，
我们进行网络的读取，不仅仅可以使用read/write接口，还可以使用recv/send这一对接口，这两个接口不能用来读取udp，只能读取tcp，是面向字节流的读取。
recv/send的flags默认设为0。Command类的设计如下，HandlerCommand函数用于处理客户端传来的字符串，通过Excute函数来把传入的字符串做解释，
那在Excute拿到待解释的命令行字符串后，怎么解释这个字符串呢？我们可以使用popen函数调用：
popen内部会建立一个管道文件，然后创建子进程，执行对应的command命令，内部来帮我们做命令行解析，解析后的内容放到管道文件中，返回FILE*，让我们以文件的方式读取管道。换句话说，未来只需要命令字符串传给popen就可以了，像读文件一样把结果读出来。第二个参数type是"r"/"w"/"a"。通过pclose把对应的管道文件关闭。
class Command
{
public:Command(){_safe_command.insert("ls");_safe_command.insert("touch");_safe_command.insert("pwd");_safe_command.insert("whoami");_safe_command.insert("which"); }~Command(){}bool CheckSafe(const std::string& cmdstr){for(auto e : _safe_command){if(strncmp(e.c_str(), cmdstr.c_str(), e.size()) == 0){return true;}}return false;}std::string Excute(const std::string& cmdstr){if(!CheckSafe(cmdstr)) return "unsafe";FILE* fp = popen(cmdstr.c_str(), "r");std::string result;if(fp){char line[1024];while(fgets(line, sizeof(line), fp)){result += line;}return result;}return "excute error";}void HandlerCommand(int sockfd, InetAddr addr){while (true){char commandbuff[1024];ssize_t n = ::recv(sockfd, commandbuff, sizeof(commandbuff) - 1, 0); // TODOif (n > 0){commandbuff[n] = 0;LOG(INFO, "get command from client %s, command : %s\n", addr.AddrStr(), commandbuff); std::string result = Excute(commandbuff);::send(sockfd, result.c_str(), result.size(),0);}else if (n == 0){LOG(INFO, "client %s quit\n", addr.AddrStr().c_str());break;}else{LOG(ERROR, "read error: %s quit\n", addr.AddrStr().c_str());}}}
private:std::set<std::string> _safe_command;
};运行结果如下：
实际上，我们打开Xshell，实际上是打开了一个客户端，在Xshell上输入命令，其实是将命令发送到远端，去请求服务器上的一个长启动的服务，把命令行字符串交给它，由它执行并推送给客户端执行结果。所以，我们所谓的命令执行就是推送到远端。
V4_Echo_Server线程池版本
实际上，这种Service长服务不太适合用线程池，因为线程池中的线程是有上限的，每个线程一直被占用。这次的线程池版本只是一个示例，未来还是要使用V2版本的多线程。创建任务类型task_t，这是线程池中任务的类型，
using func_t = std::function<void()>; 然后构建任务，放到线程池中去处理：
总结一下tcp，就是通过listensocket套接字去获取连接，把新连接和客户端地址交给别人去处理，可以多并发地去处理。