一文掌握tcp服务器epoll的多种实现

tcp服务器epoll的多种实现

  • 总结

我们在读写文件的时候,这是一款服务器,CS,这是一个服务器,这个客户端去连接服务器的时候,中间大家知道从连接的这个过程中间产生通过三次握手连接,服务器先进行监听一个端口,监听的时候是用调用listen进行监听,

TCP网络编程模型就好比这样一个模型,大家去酒店吃饭,走到那个饭店的门口门口有一个迎宾的人,有迎宾的小姐姐,然后你跟她说吃饭,她把你带进餐馆里面,然后给你介绍一个真正的服务员,后面你点菜买单,然后包括像夹菜点酒都是由这个服务员为你去服务。

这里面这个酒店出现两个人,一个是对你的迎宾的人,第二个为你服务吃饭的服务员,就这个模式。

大家可以看到客户端和服务通信也是这样一个情况,客户端就是跑到酒店去吃饭,
走到服务器这地方,服务器这里有一个listen的端口,就是迎宾的人,然后介绍一个服务员,后面客户端进行通信的时候就是介绍的这个服务员进行通信。

就是这个迎宾的人怎么让他迎宾,怎么让他开始工作?
迎宾的人上哪里去找?首先记清楚他是一个人,那这个人怎么来呢?
这里面所提到的人就是 fd,我们可以通过socket创建,创建完之后,还有比如说一个酒店特别大,比如说这个酒店特别大,它有几个门那这个迎宾的小姐姐他去那个门?他只能做一件事情,他去哪个门,所以这里我们需要绑定他在哪个门,bind()一个端口,绑定完之后,他才开始工作,真正开始工作是进入listen状态。

我想问一下这迎宾的小姐姐在listen的过程中间,他跟酒店这个管理制度有没有关系,跟这个酒店的工作流程有没有关系?没用,所以刚才讲个迎宾的小姐姐,她是一个被动的,她是一个被动的工作,就是他的工作就是listen,他不影响酒店的内部的整个工作流程,首先这点一定要记住,listen一旦进入之后,他不影响其它流程,

然后当来了一个客人之后,这时候要创建一个新的,accept才是真正接待的人,listen这个过程是指定这个迎宾的小姐姐在这个门口迎宾的工作。真的来一个客人的话,accept()介绍一个新的服务员,后面的动作点菜也好,买单也好,recv和send都是跟这个服务员之间沟通,包括close买单的时候也是。

服务器它写代码的就这么写,它就是这些接口,这个listen这个过程他就是让这个小姐姐在门口迎宾,然后剩下的就是小姐姐把这个人带进去介绍一个新的服务员

这个过程,三次握手是服务员在迎宾的这个过程中间发生的,三次握手他是被动发生的,

三次握手是在这个迎宾的人在这等待的过程中间完成,三次握手之后才把他介绍了这个新的服务员,
有人吃饭你们有人问到你是在这吃饭都说是的,这个过程叫三次握手,收到客户说是的,再把他带进去介绍服务员,

客户端这边首先吃饭,客户端也是一个人,这个人也通过socket创建的,创建完对应的他去哪里吃饭,他去哪里吃饭?准备一个地址,准备一个地址然后connect。

这个过程就是客户端连接服务器,这个过程可以绑定也可以不绑定,这个绑定的就相当于这个他出去吃饭,他的的每个门主他可以从大门走也可以小门,所以这个都okay,如果只允许他从正门走,那这时候就给他绑定一下

它是去连接的,你可以绑定也可以不绑定,所以我认为在客户当中出现了两个地址,一个是绑定的,一个是不绑定的,绑定和绑定它是一个可选项,它是一个可选项

客户端调用contact函数就是决定了它去连接这个服务器,每一个服务器IP地址端口都是多少,去找哪个酒店迎宾的小姐姐,这是确定的是在connect确定的,
这地方就连接完成之后再调用的是send和recv这是网络编程的整个流程。

这是网络编程核心的,以这些东西为基础就衍生出来了很多的做法,客户端和服务器就是这个流程

udp的服务器该怎么做?
udp就好比你去一个小餐馆,那个迎宾的人跟服务员他是一个人,就是你去了一个小饭店,没有连接在这方面,这个客户端和服务器之间不涉及到任何的连接,这个应该不用去争议的时候,

我们在设计函数的时候它的功能要做到单一讲究的一个功能,就是还是单一功能单一越单一越好。可利用可复用性就越强,就是一个函数设计功能越单一,它的可复用性就会越强,一个函数它越符号它的可复用性就越低。

recvfrom函数就有点意思,它不单只接收数据,并且还把哪个客户端给谁发都带出来了,就是recvfrom函数数据是谁发的都知道。

那现在考虑一下,比如说现在有三个udp的客户端,就是三个函数,同样都是都用sendto都是发给这一个端口,都是recvfrom由他来一个接受,

就好比一个小的餐馆,现在这个餐馆只有一个迎宾的人,现在过去了多批人多活人同时走到这个门口,我就想问一下,那这个迎宾的人,他能分清楚这三户人?他不可以,

这个服务端我们只有1个,然后如果10个1000个2000个同时调用sendoto,
我就想问一下那这个服务呢它能区分区分不了,区分不了也就是换一个说法,udp的服务器如何做多个客户端并发?

那也就是我们在udp的这个基础上面recvfrom,可能很多人会想一个办法,就是buffer里面想办法,也就是说从客户端发到服务器的时候,这个数据上面想办法,
就是我定义一种本地的协议,就是说我发送的数据包我知道是购买a发的,购完b发的数据我能知道它是b发的,然后c发的我就知道那可能同学在想的,就是我能不能通过这个数据包括应用协议来解决这个问题

就是给buffer加客户端头,但是客户端口端加客户端头是有一个巨大的前提?

我们现在讲的第一个方法就是在我们发送的数据包上面加一层协议能不能行?
好很多朋友认为可以,好,
我跟大家讲一下不可以,为什么?

其它是有很大的前提,就是需要顺序的接收,就是需要顺序接收这是可以的。
就是我们知道a发的先到先发的先到后,发的后到那这种情情况下面它是ok的,那你可以在协议里面加一协议,这是可以的,在公网的情况下,面udp是很难保证先发的先到后发的后报可能有可能先发的数据后到后发的,数据先到。

第二种方法
其实原理也很简单,请他注意那我们用udp来做,其他注意我们也可以仿造了刚刚TCP这个迎宾的这个模式迎宾的这个人的模式,那么也我们也可以仿照这个模式,
好这样一个模式做,那怎么做呢你怎么做对吧?

我们也是这样的,创建一个迎宾的人在这里等着,
也就客户他先sendto给服务器这个迎宾的人创建一个,然后迎

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值