服务器模型??

1、循环服务器模型:循环处理客户端,处理完一个继续处理下一个。

缺点:不能同时处理多个请求,不允许某个客户端长期占用服务器资源

udp是不需要进行连接的,所以循环服务器模型更加适合udp通信。

2、并发服务器模型:每有一个客户端就创建一个进程/线程处理客户端的具体请求,而主进程/线程继续接收其他客户端的连接。

3、io多路复用:  一个socket同时监控多个io事件,当哪个io事件就绪就执行哪个io事件,形成一种并发的效果。

4、协程服务器模型:协程,微线程、单程。是一种用户态的轻量级线程。

1、轻量级,创建消耗资源较少

2、不涉及内核

优点:无需上下文切换的开销

     无需同步互斥操作

     有较高的并发性

   创建消耗资源较少

缺点:无法利用计算机的多核资源

     遇到死循环等阻塞状态会影响整个程序的运行。

原文地址:https://www.cnblogs.com/lmh001/p/9755641.html

时间: 2024-09-19 01:56:29

服务器模型??的相关文章

非阻塞IO服务器模型

我们来考虑一个情形,你跟千千万万个玩家是魔兽世界的超级粉丝,每周末准时组团打boss.每当周末游戏服务器就亚历山大,因为起码几十万用户同时在线.如果用我们的多线程阻塞服务器作为游戏服务器是否可行呢?先分析游戏服务器有哪些特点: ①  网络游戏并非像网页一样,打开一旦下载完就可以关闭连接结束.网游必须是有一个持久有状态的连接,每一个客户端都需要跟服务器存在一个持久的连接,以便快速及时发送消息.而随着并发用户数量的增加,多线程阻塞服务器不可能为每一个客户端分配一个线程. ②  跟一般的应用服务器不同

阻塞IO服务器模型之多线程服务器模型

针对单线程服务器模型的特点,我们可以对其进行改进,使之能对多个客户端同时进行响应.最简单的改进即是使用多线程(或多进程)服务器模型,在应用层级别,我们一般采用多线程模式.多线程能让多个客户端同时请求,并能几乎同时对这些请求进行响应,而不用排队一个一个处理,能同时为多个客户端提供一问一答的服务. 图2-6-1-2 多线程阻塞服务器模型 多线程服务器模型核心就是利用多线程机制,为每个客户端分配一个线程.如图2-6-1-2,服务器初始化一个Serversocket实例,绑定某个端口号,并使之监听客户端

阻塞IO服务器模型之单线程服务器模型

单线程服务器模型是最简单的一个服务器模型,几乎我们所有程序员在刚开始接触网络编程(不管是B/S结构还是C/S结构)都是从这个简单的模型开始.这种模型只提供同时一个客户端访问,多个客户端访问必须要等到前一个客户端访问结束,一个一个排队,即提供一问一答服务. 图2-6-1-1 单线程阻塞服务器模型 图2-6-1-1展示了单线程阻塞服务器是怎样响应客户端的访问.首先,服务器必须初始化一个Serversocket实例,绑定某个端口号,并使之监听客户端的访问,以此提供一种服务.接着客户端1远程调用服务器的

Linux下常见服务器模型

Linux下常见服务器模型 到今天在公司呆了8个月,完成从校园人到职场人的转身.出身社会,感触颇多,一切身不由己.在工作中快乐过.焦虑过.失望过,到最后的心凉,这一路下来成长不少.大学毕业设计涉及网络知识,当时学习了一些基础的网络知识,工作不久,转到新的项目组hms做的产品IPTV刚好和网络相关,最近几个月一直在看<linux高性能服务器编程>,在网上也看了不少文章,一直想写篇总结. 基础 图1 c/s架构通信 图1是一个简化的tcp通信过程,左侧为“服务器端”,右侧为“客户端”,tcp协议本

【转】常用服务器模型总结

UNPv3上一共总结了9种服务器模型分别是: 1.迭代服务器 2.并发服务器,为每个客户fork一个进程 3.预先派生子进程,每个子进程都调用accept,accept无上锁保护 4.预先派生子进程,以文件锁的方式保护accept 5.预先派生子进程,以线程互斥锁上锁的方式保护accept 6.预先派生子进程,由父进程向子进程传递套接口描述字 7.并发服务器,为每个客户请求创建一个线程 8.预先创建线程,以互斥锁上锁方式保护accept 9.预先创建线程,由主线程调用accept,并把每个客户连

基于NIO的服务器模型

最简单服务器模型是thread-per-connection,即每个客户端连接对于一个专属的工作线程,工作线程等待客户端发送数据.接收处理数据.返回响应数据然后继续等待新的数据的到来,这种模型能够保证很好的响应速度,但如果有大量并发连接会导致大量的工作线程,而且这些线程浪费了很多时间等待新数据,这些导致了这种服务器模型不适合高并发的情况. 如果服务器需要应对大量但可能并不实时活跃的连接,那么thread-on-event模型就比较适合.这种模型工作线程独立于客户端连接,只用来处理特定的事件,例如

0731------Linux网络编程----------论封装的乐趣(select、poll、epoll 服务器模型的封装)

0.春阳语录,代码嵌套三层以上就是一坨垃圾.因此良好的编程风格从封装开始. 1.封装select服务器模型 1.1 如何封装?将select需要的数据结构都封装成结构体,通过参数在函数之间传递,将固定的操作封装成相应的函数. 1.2 封装后的程序: 1.2.1 封装的头文件 select_t.h #ifndef __SELECT_T_H__ #define __SELECT_T_H__ #include <sys/select.h> #include <sys/types.h> #

synapse socket总结一:服务器模型

synapse (http://synapse.ararat.cz/doku.php)的源码简洁明了,属于轻量级的阻塞式socket通讯组件包,更多的功能需要自己基于它的基础上去封装实现.相对于indy(阻塞)和ics(非阻塞/阻塞)来说,我更喜欢synapse的原生和纯粹,因此对其进行了简单的学习和总结.在着手学习synapse之前,有必要先对常见的服务器模型做下回顾,这对接下来解读synapse代码非常有帮助.在目前的网络应用中,大多数是一个服务端对应多个客户端的联网方式,那么我就着重分析一

对libevent+多线程服务器模型的C++封装类

最近在看memcached的源码,觉得它那种libevent+多线程的服务器模型真的很不错,我将这个模型封装成一个C++类,根据我的简单测试,这个模型的效率真的很不错,欢迎大家试用. 这个类的使用方法很简单(缺点是不太灵活),只要派生一个类,根据需要重写以下这几个虚函数就行了: //新建连接成功后,会调用该函数virtual void ConnectionEvent(Conn *conn) { }//读取完数据后,会调用该函数virtual void ReadEvent(Conn *conn) 

几种并发服务器模型的实现:多线程,多进程,select,poll,epoll

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/socket.h> #include <arpa/inet.h> #include &q