TCP/IP 三次握手后该怎么去理解read和write函数中的参数?

发布于 2022-09-11 18:20:39 字数 638 浏览 61 评论 0

初学网络编程,自己写服务端和客户端简单的socket通信时,遇到了一个问题比较迷惑:

在服务端编程时,会创建两个文件描述符sfd和cfd,其中sfd用来绑定服务端的地址信息,后面调用accept的时候,使用的实参是sfd,返回给了cfd,最终用read和write函数的时候,都是通过cfd来进行读写的,(个人感觉这里的cfd是否就可以理解是保存了客户端的地址信息,相当于客户端的套接字?)也就是说这里读写时使用的是对方的套接字进行读写的?

然后到了客户端编程时,只创建了一个文件描述符fd,然后后面使用connect函数时,实参使用的也是这个fd,而后面使用read和write时,也是通过fd来进行读写的。但是我从一些资料上看到,客户端如果没有给套接字使用bind,操作系统会自动分配地址信息绑定到这个套接字上,那就说明客户端中的fd依然是客户端自身的套接字?

这样我就觉得很奇怪了:为什么在服务端read和write是用的对方的套接字,而客户端read和write时是用的自己的套接字呢?既然都用的是相同的函数,那这样不就矛盾了吗?

请问我是哪里理解错了呢?

(另外,个人对于套接字的理解是:套接字实际上就是将一个进程的地址信息(包括ip、端口等)具体化,来使得进程成为一个可连接对象,不知道这样的理解是否有误?)

 
十分感谢!!!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

那请放手 2022-09-18 18:20:39
  1. 描述符都是本地的概念,它的值只是内核文件系统中对socket/sock数据结构的一个"别称"而已。创建socket时,内核创建socket/sock数据结构,并返回给你一个fd。以后你用这个fd进行 send或者recv,内核才能找到时哪个socket。

(个人感觉这里的cfd是否就可以理解是保存了客户端的地址信息,相当于客户端的套接字?)也就是说这里读写时使用的是对方的套接字进行读写的?

cfd是属于Server的套接字描述符,只是它对应的套接字保存了通信双方的信息,只能说是连接到client的套接字

客户端如果没有给套接字使用bind,操作系统会自动分配地址信息绑定到这个套接字上,那就说明客户端中的fd依然是客户端自身的套接字?

Bind 就是手动指定为一个套接字指定本端地址信息(比如IP和port)。一般Clinet不关心自己使用的端口号,所以一般Clinet不用Bind,实在要Bind也没啥问题,只要不要和已有的冲突就行。

另外,关于

在服务端编程时,会创建两个文件描述符sfd和cfd,其中sfd用来绑定服务端的地址信息,后面调用accept的时候,使用的实参是sfd,返回给了cfd

sfd是监听(listen)套接字,accept返回的cfd是子连接,本端信息继承sfd,对端信息来源于对端的SYN报文

寂寞陪衬 2022-09-18 18:20:39

套接字可以理解为一条通道,是双方共有的,不存在是属于谁的问题。

此外,服务端由于要接受客户端的请求,需要额外使用一个文件描述符

妄想挽回 2022-09-18 18:20:39

fd, 文件描述符, 相当于指针。根据fd可以找到socket绑定的信息。
问题的关键是,服务端用自己的套接字是没有绑定客户端的信息的,它不知道要发送到哪。

爱本泡沫多脆弱 2022-09-18 18:20:39

一个连接有两个端点,服务端一个,客户端一个,没毛病啊。

serversocket是一个特殊的socket,它可以监听和接受客户端的连接,接受之后就会返回一个具体的连接。

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文