在面试时,可能会被问到 epoll 相关的问题。比如 epoll 和 select 二点区别是什么?epoll 高效率的原因是什么?如果只靠背诵,显然不能算得上深刻的理解。
本文会从网卡接收数据的流程将其,串联起 CPU 中断、操作系统进程调度等知识;再进一步分析阻塞接收数据、select 到 epoll 的进化过程;最后探究 epoll 的实现细节。
目录如下:
一、从网卡接收数据说起
二、如何知道接受了数据
三、进程阻塞为什么不占用 CPU 资源?
四、内核接收网络数据全过程
五、同时监视多个 socket 的简单方法
六、epoll 的设计思路
七、epoll 的原理和流程
八、epoll 的实现细节
九、结论
下图是一个典型的计算机结构图,计算机由 CPU、存储器(内存)、网络接口等部件组成。了解 epoll 本质的第一步,就是要从硬件的角度看计算机怎样接收网络数据。
下图展示了网卡接收数据的全过程。
这个过程涉及到 DMA 传输、IO 通路选择等硬件有关的知识,但是我们只需要知道:网卡会把接收到的数据写入内存。通过硬件传输,网卡接收的数据存放在内存中。操作系统就可以去读取它们。
了解 epoll 本质的第二步,要从 CPU 的角度来看接收数据。要理解这个问题,要先了解一个概念 —— 中断。
计算机执行程序时,会有优先级的需求。比如,当计算机收到断电信号时(电容可以保存少许电量,供 CPU 运行很短的一小段时间),它应立即去保存数据,保存数据的程序具有较高优先级。
一般而言,由硬件产生的信号需要 CPU 立马做出回应(不然数据可能就丢失),所以它的优先级很高。CPU 理应中断掉正在执行的程序,去做出响应;当 CPU 完成对硬件的响应后,再重新执行用户程序。中断的过程如下,和函数调用差不多。只不过函数调用是事先定好位置,而中断的位置由 “信号” 决定。
以键盘为例,当用户按下键盘某个按键时,键盘会给 CPU 的中断引脚发出一个高电平。CPU 能够捕获这个信号,然后执行键盘中断程序。下图展示了各种硬件通过中断与 CPU 交互。
现在可以回答本节提出的问题了:当网卡把数据写入内存后,网卡向 CPU 发出一个中断信号,操作系统便能得知有新数据到来,再通过网卡中断程序去处理数据。
了解 epoll 本质的第三步,要从操作系统进程调度的角度来看接收数据。阻塞是进程调度的关键一环,指的是进程在等待某事件(如接收到网络数据)发生之前的等待状态,recv、select 和 epoll 都是阻塞方法。了解 “进程阻塞为什么不占用 CPU 资源?”,也就能够了解这一步。
为简单起见,我们从普通的 recv 接收开始分析,先看看以下代码:
//创建socket
int sockfd = socket(AF_INET, SOCK_STREAM, 0);
//绑定
bind(sockfd , ...)
//监听
listen(sockfd , ...)
//接受客户端连接
int connfd = accept(sockfd , ...)
//接收客户端数据
recv(connfd, ...);
//将数据打印出来
printf(...)
这是一段最基础的网络编程代码,先新建 socket 对象,依次调用 bind、listen、accept,最后调用 recv 接收数据。recv 是个阻塞方法,当程序运行到 recv 时,它会一直等待,直到接收到数据才往下执行。
那么阻塞的原理是什么?
工作队列
操作系统为了支持多任务,实现了进程调度的功能,会把进程分为 “运行” 和 “等待” 等几种状态。运行状态是进程获得 CPU 使用权,正在执行代码的状态;等待状态是阻塞状态,比如上述程序运行到 recv 时,程序会从运行状态变为等待状态,接收到数据后又变回运行状态。操作系统会分时执行各个运行状态的进程,由于速度极快,看上去就像是同时执行多个任务。
下图中的计算机中运行着 A、B、C三个进程,其中进程 A 执行着上述基础网络程序,一开始,这3个进程都被操作系统的工作队列所引用,处于运行状态,会分时执行。
等待队列
当进程 A 执行到创建 socket 的语句时,操作系统会创建一个由文件系统管理的 socket 对象(如下图)。这个 socket 对象包含了发送缓冲区、接收缓冲区、等待队列等成员。等待队列是个非常重要的结构,它指向所有需要等待该 socket 事件的进程。
当程序执行到 recv 时,操作系统会将进程 A 从工作队列移动到该socket 的等待队列中(如下图)。由于工作队列只剩下了进程 B 和 C,根据进程调度,CPU 会轮流执行这两个进程,不会执行进程 A 的程序。所以进程 A 被阻塞,不会往下执行代码,也不会占用 CPU 资源。
PS:操作系统添加等待队列只是添加了对这个 “等待中” 进程的引用,以便在接收到数据时获取进程对象,将其唤醒,而非直接将进程管理纳入自己之下。上图为了方便说明,直接将进程挂到了等待队列之下。
唤醒进程
当 socket 接收到数据之后,操作系统将该 socket 等待队列上的进程重新放回到工作队列,该进程变成运行状态(当 socket 事件触发时,也就是有数据到来,会取下一个进程结构调用其回调,将其挂到工作队列),继续执行代码。也由于 socket 的接收缓冲区已经有了数据,recv 可以返回接收到的数据。
这一步,贯穿网卡、中断、进程调度的知识,叙述阻塞 recv 下,内核接收数据全过程。
如下图所示,进程在 recv 阻塞期间,计算机收到了对端传送的数据(步骤①)。数据经由网卡传送到内存(步骤②),然后网卡通过中断信号通知 CPU 有数据到达,CPU 执行中断程序(步骤③)。此处的中断程序主要有两项功能,先将网络数据写入对应 socket 的接收缓冲区里面(步骤④),再唤醒 A(步骤⑤),重新将 A 进程放入工作队列中。
唤醒进程的过程如下图所示:
以上是内核接收数据的全过程
这里留有两个思考题,大家先想一想。
其一,操作系统如何知道网络数据对应于哪个 socket?
其二,如何同时监视多个 socket 的数据?
(———— 我是分割线,想好了才能往下看哦~)
公布答案的时间到了
第一个问题:因为一个 socket 对应着一个端口号,而网络数据包中包含了 ip 和端口的信息,内核可以通过端口号快速找到对应的 socket。当然,为了提高处理速度,操作系统会维护端口号到 socket 的索引结构,以快速读取。(就是说网卡中断 CPU 后,CPU 的中断程序从网卡存数据的内存拷贝到对应 fd 的接收缓冲区,具体是哪一个 fd,CPU 会检查 port,放到对应的 fd中)
第二个问题是多路复用的重中之重,是本文后半部分的重点!
服务端需要管理多个客户端连接,而 recv 只能监视单个 socket,这种矛盾下,人们开始寻找监视多个 socket 的方法。epoll 的要义是高效的监视多个 socket。从历史的发展角度看,必然先出现一种不太高效的方法,人们再加以改进。只有先理解了不太高效的方法,才能够理解 epoll 的本质。
假如能够预先传入一个 socket 列表,如果列表中的 socket 都没有数据,挂起进程,直到有一个 socket 收到数据,唤醒进程。这种方法很直接,也是 select 的设计思想。
为方便理解,我们先复习 select 的用法。在如下的代码中,先准备一个数组(下列代码中 fds),让 fds 存放着所有需要监视的 socket。然后调用 select,如果 fds 中的所有 socket 都没有数据,select 会阻塞,直到有一个 socket 接收到数据,select 返回,唤醒进程。用户可以遍历 fds,通过 FD_ISSET 判断具体哪个 socket 收到数据,然后做出处理。
int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...)
listen(s, ...)
int fds[] = 存放需要监听的socket
while(1){
int n = select(..., fds, ...)
for(int i=0; i < fds.count; i++){
if(FD_ISSET(fds[i], ...)){
//fds[i]的数据处理
}
}
}
select 的流程
select 的实现思路很直接。假如程序同时监视如下图的 sock1、sock2 和 sock3 三个 socket,那么在调用 select 之后,操作系统把进程 A (其实是进程 A 的引用)分别加入这三个 socket 的等待队列中。
当任何一个 socket 收到数据之后,中断程序将唤起进程。下图展示了 sock2 接收到了数据的处理流程。
PS:recv 和 select 的中断回调可以设置成不同的内容
所谓唤起进程,就是将进程从所有的等待队列中移除,加入到工作队列里面。如下图所示。
经由这些步骤,当进程 A 被唤醒后,它知道至少有一个 socket 接受了数据。程序只需遍历一遍 socket 列表,就可以得到就绪的 socket。
这种简单方法行之有效,在几乎所有操作系统都有对应的实现。
但是简单的方法往往有缺点,主要是:
其一,每次调用 select 都需要将进程加入到所有 socket 的等待队列,每次唤醒都需要从每个队列中移除。这里涉及了两次遍历(遍历进程 A 关心的所有 socket,需要注意的是添加从等待队列头部添加,删除通过回调直接实现,所以每个 socket 的等待队列不用遍历),而且每次都要将整个 fds 列表传递给内核,有一定的开销。正是因为遍历操作开销大,处于效率的考量,才会规定 select 的最大监视数量,默认只能监视 1024 个 socket。
其二,进程被唤醒后,程序并不知道哪些 socket 收到数据,还需要遍历一次。
那么,有没有减少遍历的方法?有没有保存就绪 socket 的方法?这两个问题都是 epoll 技术需要解决的。
补充说明:
本节只解释了 select 的一种情形。当程序调用 select 时,内核会先遍历一遍 socket,如果有一个或一个以上的 socket 的接收缓冲区有数据,那么 select 直接返回,不会阻塞。这也是为什么 select 的返回值有可能大于 1 额原因之一。如果没有 socket 有数据,进程才会阻塞。
epoll 是在 select 出现 N 年后才被发明的,是 select 和 poll 的增强版本。epoll 通过以下措施来改进效率。
措施一:功能分离
select 低效的原因之一是将 “维护等待队列” 和 “阻塞进程” 两个步骤合二为一。如下图所示,每次调用 select 都需要这两步操作,然而大多数应用场景中,需要监视的 socket 相对固定,并不需要每次都修改。epoll 将这两个操作分开,先用 epoll_ctl 维护等待队列,再调用 epoll_wait 阻塞进程(解耦)。显而易见,效率就能得到提升。
为方便理解后续的内容,我们先复习下 epoll 的用法。如下的代码中,先用 epoll_create 创建一个 epoll 对象 epfd,再通过 epoll_ctl 将需要监视的 socket 添加到 epfd 中,最后调用 epoll_wait 等待数据。
int s = socket(AF_INET, SOCK_STREAM, 0);
bind(s, ...)
listen(s, ...)
int epfd = epoll_create(...);
epoll_ctl(epfd, ...); // 将所有需要监听的 socket 添加到 epfd 中
while(1)
{
int n = epoll_wait(...);
for(接收到数据的socket)
{
// 处理
}
}
功能分离,使得 epoll 有了优化的可能。
措施二:就绪列表
select 低效的另一个原因在于程序不知道哪些 socket 收到数据,只能一个个遍历。如果内核维护一个 “就绪列表”,引用收到数据的 socket,就能避免遍历。如下图所示,计算机共有三个 socket,收到数据的 sock2 和 sock3 被 rdlist(就绪列表)所引用。当进程被唤醒后,只要获取 rdlist 的内容,就能够知道哪些 socket 收到数据。
这里引出了另一个问题:什么时候 select 优于 epoll?
一般认为在并发量低,socket 都比较活跃的情况下,select 的效率更高,也就是说活跃 socket 数目与监控的总的 socket 数目之比越大,select 效率越高,因为 select 反正都会遍历所有的 socket,如果比例大,就没有白白遍历。加之 select 本身实现比较简单,导致总体现象比 epoll 好。
本节会以示例和图表来讲解 epoll 的原理和流程。
创建 epoll 对象
如下图所示,当某个进程调用 epoll_create 方法时,内核会创建一个 eventpoll 对象(也就是程序中 epfd 所代表的对象)。eventpoll 对象也是文件系统的一员,和 socket 一样,它也会有等待队列(有线程会等待其事件触发,比如调用 epoll_wait 的线程就会阻塞在其上)。
创建一个代表该 epoll 的 eventpoll 对象是必须的,因为内核要维护 “就绪列表” 等数据,“就绪列表” 可以作为 eventpoll 的成员。
维护监视列表
创建 epoll 对象后,可以用 epoll_ctl 添加或删除所要监听的 socket。以添加 socket 为例,如下图,如果通过 epoll_ctl 添加 sock1、sock2 和 sock3 的监视,内核会将 eventpoll 添加到这三个 socket 的等待队列中。
当 socket 收到数据后,中断程序会操作 eventpoll 对象,而不是直接操作进程。
接收数据
当 socket 收到数据后,中断程序会给 eventpoll 的 “就绪列表” 添加 socket 引用。如下图展示的是 sock2 和 sock3 收到数据后,中断程序让 rdlist 引用这两个 socket。
eventpoll 对象相当于是 socket 和 进程之间的中介,socket 的数据接收并不直接影响进程,而是通过改变 eventpoll 的就绪列表来改变进程状态。
当程序执行到 epoll_wait 时,如果 rdlist 已经引用了 socket,那么 epoll_wait 直接返回,如果 rdlist 为空,阻塞进程。
阻塞和唤醒进程
假设计算机中正在运行进程 A 和 进程 B,在某时刻进程 A 运行到了 epoll_wait 语句。如下图所示,内核会将进程 A 放入 eventpoll 的等待队列中,阻塞进程。
当 socket 接收到数据,中断程序一方面修改 rdlist,另一方面唤醒 eventpoll 等待队列中的进程,进程 A 再次进入到运行状态(如下图)。也因为 rdlist 的存在,进程 A 可以知道哪些 socket 发生了变化。
至此,相信读者对epoll的本质已经有一定的了解。但我们还留有一个问题,eventpoll的数据结构是什么样子?
再留两个问题,就绪队列应该使用什么数据结构?eventpoll 应使用什么数据结构来管理通过 epoll_ctl 添加或删除的 socket?
(———— 我是分割线,想好了才能继续往下看哦~)
如下图所示,eventpoll 包含了 lock、mtx、wq(等待队列)、rdlist 等成员。rdlist 和 rbr 是我们所关心的。
就绪列表(rdlist)的数据结构
就绪列表引用就绪的 socket,所以它应能够快速的插入数据。
程序可能随时调用 epoll_ctl 添加监视的 socket,也可能随时删除。当删除时,若该 socket 已经存放在就绪列表中,它也应该被移除。(事实上,每个 epoll_item 既是红黑树节点,也是链表节点,删除红黑树节点,自然删除了链表节点)
所以就绪列表是一种能够快速插入和删除的数据结构。双向链表就是这样一种数据结构,epoll 使用双向链表来实现就绪队列(对应上图的 rdlist)。
索引结构
既然 epoll 将 “维护监视队列” 和 “进程阻塞” 分离,也意味着需要有个数据结构来保存监视的 socket。至少要方便的添加和删除,还要便于搜索,以避免重复添加。红黑树是一种平衡二叉搜索树,搜索、插入和删除时间复杂度都是 O(logn),效率较好。epoll 使用了红黑树作为索引结构。(对应上图的 rbr)。
PS:因为操作系统要兼顾多种功能,以及有很多需要保存的数据,rdlist 并非直接引用 socket,而是通过 epitem 间接引用,红黑树的节点也是 epitem 对象。同样,文件系统也并非直接引用着 socket。为方便理解,本文中省略了一些间接结构。
epoll 在 select 和 poll(poll 和 select 基本一样,有少量改进)的基础引入了 eventpoll 作为中间层,使用了先进的数据结构,是一种高效的多路复用技术。
下表是一个很常见的表,描述了 select、poll 和 epoll 的区别。读完本文,读者是否能解释 select 和epoll 的时间复杂度为什么是 O(n) 和 O(1)?
系统调用 | select | poll | epoll |
---|---|---|---|
事件集合 | 用户通过3个参数分别传入感兴趣的可读、可写及异常等事件。内核通过对这些参数的在线修改来反馈其中的就绪事件。这使得用户每次调用 select 都要重置这三个参数 | 统一处理所有事件类型,因此需要一个事件集参数。用户通过 pollfd.events 传入感兴趣的事件,内核通过修改 pollfd.revents 反馈其中就绪的事件 | 内核通过一个事件表直接管理用户感兴趣的所有事件。因此每次调用 epoll_wait 时,无须反复传入用户感兴趣的事件。epoll_wait 系统调用的参数 events 仅用来反馈就绪的事件 |
应用程序索引就绪文件描述符的时间复杂度 | O(n) | O(n) | O(1) |
最大支持文件描述符数 | 一般有最大限制(1024) | 65535 | 65535 |
工作模式 | LT | LT | 支持 ET 高效模式 |
内核实现和工作效率 | 采用轮询方式检测就绪事件(select 返回后还需要循环遍历所有 fd),算法时间复杂度为 O(n) | 采用轮询方式检测就绪事件,算法时间复杂度为 O(n) | 采用回调方式检测就绪事件(epoll 返回的只有改变了状态的 fd)。算法时间复杂度为 O(1) |
epoll 有 EPOLLLT 和 EPOLLET 两种触发模式,LT 是默认的模式,ET 是“高速”模式。
LT(水平触发) 和 ET(边沿触发) 的区别
LT
:描述符上有数据就绪时,在提醒用户后,如果用户没有将该数据读完(处理完),在下一轮循环中 io 函数会继续提醒用户该描述符有数据就绪,直到用户将该描述符上的所有数据读完。这样的特点使得 LT 工作模式具有可靠但低效率的特点。ET
:描述符上有数据就绪时,在提醒用户后,如果用户没有将该数据读完(处理完),在下一轮循环中 io 函数不会再次提醒用户该描述符有数据就绪,除非该描述符上有新数据到达。这样的特点使得 ET 工作模式具有高效率但不可靠的特点。
还有一个特点是,epoll 使用“事件”的就绪通知方式,通过 epoll_ctl 注册 fd,一旦该 fd 就绪,内核就会采用类似 callback 的回调机制来激活该 fd,epoll_wait 便可以收到通知。
简单总结一下:
epoll 不会让每个 socket 的等待队列都添加进程 A 引用,而是在等待队列,添加 eventpoll 对象的引用。当 socket 就绪时,中断程序会操作 eventpoll,在 eventpoll 中的就绪列表(rdlist),添加 socket 引用。这样的话,进程 A 只要不断轮询 rdlist,从而获取就绪的 socket。从代码来看每次执行到 epoll_wait,其实都是去遍历 rdlist。如果 rdlist 为空,那么就阻塞进程;当有 socket 处于就绪状态,也是发中断信号,再调用对应的中断程序。此处中断程序,会把 socket 加到 rdlist,然后唤醒进程。进程再去遍历 rdlist,获取就绪的 socket。
总之:poll 是翻译轮询的意思,我们可以看到 poll 和 epoll 都有轮询的过程。
不同点在于:poll 轮询的是所有的 socket,而 epoll 只轮询就绪的 socket。
epoll 的适用场景,更适合处理高并发的场合。如果并发量很少,比如几百个连接这个级别,select 的效率会比 epoll 高,只有连接数达到一定程度,epoll 的额外消耗才能抵消 select 的遍历。
Redis 是单线程,为什么这么快?
- redis 是纯内存操作,除了网络 IO,不涉及其它 IO 操作;
- 其中的单线程指的只有一个线程里面有 epoll,只有一个 epoll 来管理。没有多线程切换以及加锁机制
主要包含三个文件:SocketAPI.h、server.cc、client.cc
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace std;
#define LISTEN_QUEUE SOMAXCONN
#define MAX_FILENAME_SIZE 256
#define BUFFER_SIZE 4096
#define IP_SIZE 20
class SockAPI{
public:
//创建套接字
static int Socket(int type)
{
int sockfd;
sockfd = socket(AF_INET, type, 0);
if(sockfd < 0)
{
assert(sockfd >= 0);
perror("socket error");
exit(1);
}
cout << "socket success\n";
return sockfd;
}
//命名套接字
static void Bind(int sockfd, int port)
{
int ret;
struct sockaddr_in server_addr;
server_addr.sin_family = AF_INET;
//server_addr.sin_addr.s_addr = inet_addr("192.....");
server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
server_addr.sin_port = htons(port);
ret = bind(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr));
if(ret < 0)
{
assert(ret >= 0);
perror("bind error");
exit(1);
}
cout << "bind success\n";
}
//监听端口
static void Listen(int sockfd)
{
int ret = listen(sockfd, LISTEN_QUEUE);
if(ret < 0)
{
assert(ret = 0);
perror("listen error");
exit(1);
}
cout << "listening\n";
}
//发起连接请求
static void Connect(int sockfd, char* ip, int port)
{
int ret;
struct sockaddr_in server_addr;
server_addr.sin_family = AF_INET;
server_addr.sin_addr.s_addr = inet_addr(ip);
server_addr.sin_port = htons(port);
ret = connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr));
if(ret < 0)
{
assert(ret = 0);
perror("connect error");
exit(1);
}
cout << "connect success\n";
}
//接受请求
static int Accept(int sockfd, string &out_ip, int &out_port)
{
int connfd;
struct sockaddr_in client_addr;
socklen_t len = sizeof(client_addr);
connfd = accept(sockfd, (struct sockaddr*)&client_addr, &len);
if(connfd < 0)
{
assert(connfd = 0);
perror("accept error");
exit(1);
}
out_ip = inet_ntoa(client_addr.sin_addr);
out_port = htons(client_addr.sin_port);
cout << "accept success " << out_ip << endl; ;
return connfd;
}
//关闭连接
static void Close(int connfd)
{
close(connfd);
}
};
/**********************************************************
> File Name: server.c
> Author: Darwlr
> Created Time: 2020年08月17日 星期一 12时22分10秒
*********************************************************/
#include "server.h"
#define TCP_SERVER_PORT 6666 /* 服务器的端口 */
#define EPOLL_SIZE 256
void SignalChild(int signo)
{
pid_t pid;
int status;
while((pid = waitpid(-1, &status, WNOHANG) > 0))
{
printf("child %d terminated\n", pid);
}
return;
}
extern int errno;
int main(int argc, char *argv[])
{
/**********************************************************
*
* 创建并初始化服务器套接字
*
**********************************************************/
int listenFd;
/* 创建套接字 */
listenFd = SockAPI::Socket(SOCK_STREAM);
/* 绑定端口 */
SockAPI::Bind(listenFd, TCP_SERVER_PORT);
/* 开始监听绑定的端口 */
SockAPI::Listen(listenFd);
//
struct epoll_event ev, events[EPOLL_SIZE];
ev.events = EPOLLIN;
ev.data.fd = listenFd;
int ret;
char buf[BUFFER_SIZE];
int epfd = epoll_create(EPOLL_SIZE);
if(-1 == epfd)
{
perror("epoll_create");
exit(1);
}
// 将listenFd添加到 epfd中
ret = epoll_ctl(epfd, EPOLL_CTL_ADD, listenFd, &ev);
if(-1 == ret)
{
perror("epoll_ctl");
exit(1);
}
while(1)
{
int num = epoll_wait(epfd, events, EPOLL_SIZE, -1);
if(-1 == num)
{
perror("epoll_wait");
exit(1);
}
// 遍历 events
for(int i = 0; i < num; i++)
{
if(events[i].data.fd == listenFd)
{
string out_ip;
int out_port;
int connfd = SockAPI::Accept(listenFd, out_ip, out_port);
// 将新连接的connfd注册到epfd中
ev.events = EPOLLIN;
ev.data.fd = connfd;
epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &ev);
}
else
{
if(events[i].events & EPOLLIN)
{
ret = recv(events[i].data.fd, buf, BUFFER_SIZE, 0);
if(-1 == ret)
{
perror("recv");
exit(1);
}
else if(ret == 0)
{
ev.events = EPOLLIN;
ev.data.fd = events[i].data.fd;
epoll_ctl(epfd, EPOLL_CTL_DEL, events[i].data.fd, &ev);
printf("客户端%d退出\n", events[i].data.fd);
SockAPI::Close(events[i].data.fd);
}
else
printf("收到客户端%d的消息:%s\n", events[i].data.fd, buf);
memset(buf, 0, BUFFER_SIZE);
}
}
}
}
}
/**********************************************************
> File Name: server.c
> Author: Darwlr
> Created Time: 2020年08月17日 星期一 12时22分10秒
*********************************************************/
#include "client.h"
#define TCP_SERVER_PORT 6666
int main(int argc, char *argv[])
{
char serverIp[IP_SIZE]; /* 服务器的IP地址 */
if(argc >= 2) /* 参数过多的时候,提示用户 */
{
printf("You have given to much parameters...\n");
printf("Yous should give the IP address after %s\n without any other parametes...\n", (char *)argv[0]);
}
else if(argc == 1) /* 只有一个参数,则默认使用localhost(127.0.0.1) */
{
strcpy(serverIp, "127.0.0.1");
}
else
{
strcpy(serverIp, argv[1]);
}
/**********************************************************
*
* 创建并初始化套接字
*
**********************************************************/
int socketFd; /* 客户端的套接字信息 */
/* 开始创建套接字 */
/* SOCK_STREAM 面向连接的套接字,即TCP */
socketFd = SockAPI::Socket(SOCK_STREAM);
/* 尝试连接服务器 */
SockAPI::Connect(socketFd, serverIp, TCP_SERVER_PORT);
/**********************************************************
*
* 下面进行正常的套接字通信
*
**********************************************************/
while(1)
{
string msg;
getline(cin, msg);
send(socketFd, msg.c_str(), sizeof(msg), 0);
}
return EXIT_SUCCESS;
}