Socket 与系统调用深度分析

Posted 2021-03-22 zhangguowei1070

1、什么是API：

 

 API（Application Programming Interface，应用程序接口）是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。 目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问原码，或理解内部工作机制的细节。

 

 2、实验跟踪：

在上个实验里，我们学习了gdb的基本用法，并且我们知道menuOS实质上是一个linux下的网络方面的结构部件，我们上次在其中加上了replyhi和hello功能，它们可以向我们演示TCP协议的两端相互通信的结果。但是，现在我们想要进一步发掘这两个函数背后的底层，它们用了什么系统调用，这是我们接下来要学习和探索的。

 

 

• Server将端口号和ip绑定形成服务端套接字，并监听在此端口
• Client将端口号和ip绑定形成客户端套接字，接着想Server发起请求，Server接受请求建立连接
• Server和Client互相发送数据

我们接下来要去源码中寻找和以上部分一一对应的函数：

首先打开lab3中的main.c，里面有replyhi函数的定义：

显然，里面调用了6个函数，分别是：InitializeService()、ServiceStart()、RecvMsg()、SendMsg()、ServiceStop()、ShutdownService()

类似的，hello函数里也有：

比刚才增加了两个新函数：OpenRemoteService（）以及CloseRemoteService（）。

这些函数的具体定义都不在这个文件中给出，我们把目光放前一点：

其中给出了replyhi和hello中用到的函数的详细定义。

 

 接下来我们开始验证我们的猜想：

打开qemu。注意，要加上-append nokaslr这个选项，不然可能跟踪不到断点。

我们直接在sys_socketcall这个地方打上断点。按照我们的预计，接下来在任何与tcp通信相关的调用，都会用到这个sys调用。

我们跟踪到了这个断点，去net/socket.c里面去找：

我们可以看到，call=1时候，对应着sys_socket函数，这个功能也就是给服务端创建了一个socket容器。

接下来，我们继续，直到暂时追踪不到断点为止：

我们看到，分别调用了call=2、4、5，也就是bind、listen、accept。为什么没有call=4？因为那个是connect，那是客户端的，现在服务器端用不上。为什么到了call=5就停下来了？因为现在是调用了accept，它正在等待客户端的connect。

此时，qemu上面会显示，服务器端tcp连接已经准备！

我们输入hello，接下来我们发现断点再次出现在了call=1处：

为什么呢？因为这次是客户端调用了socket（），为客户端建立了socket（）容器，和之前那个有所不同。

接下来继续c，我们发现停在了call=3；记得刚才正好缺失的call=3嘛？这回是调用了connect（），是客户端调用的。

这次好了，是call=10；这是什么？我们看到，这个就是sys_sendto（）。

接下来是连续两个call=9；这个是sys_send（）；当第二次调用sys_send（）时候，qemu出现如下信息：

我们的服务器端从客户端收到了hello的信息。

接下来又是一个call=10；

我们随即发现qemu出现如下讯息：

继续，出现了call=5，然后qemu连续显示两条信息：

 

为了证明我没撒谎，特地来个全截图：

这样就结束了吗？并没有，因为事情没有按照我的预期发展。

我们刚才预计应该会出现recv相关的断点，但是并没有。因为我数了下，call=9和call=10应该是send和sendto，怎么也对不上recv或者recvform（分别是call=11、12？）

于是我们再次实验，这次目标明确：

结果：

这次倒好，只跟踪到了sys_sendto，recv相关的函数还没影子。所以我推断，menuOS中的replyhi和hello调用的recv相关的部分不在sys_socketcall中。具体在哪里，可能要等到下个实验才能进一步探讨。

不用下一次了，马上我又做了个实验：

没有跟踪到刚才那两个断点，看来真的没有用到sys_recv和sys_recvmsg？不知何人可以回答这个问题呢？