socket read浅析

使用read函数去读取socket生成的file handle是个什么原理呢?今天研究了一下。代码的逻辑就是server段发出当前时间的字符串,client端去接收该字符串。

Server端的部分代码如下

   for ( ; ; )

    {

       connfd = accept(listenfd, (struct sockaddr *) NULL, NULL);

       if(connfd < 0)

       {

           fprintf(stderr, "accept error\n");

           return -1;

       }

 

       ticks = time(NULL);

       snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

       write(connfd, buff, strlen(buff));

       close(connfd);

}

Client端的部分代码如下

   if (connect(sockfd, (struct sockaddr *) &servaddr, sizeof(servaddr))< 0)

      fprintf(stderr, "connect error\n");

 

   while ( (n = read(sockfd, recvline, MAXLINE)) > 0) {

      recvline[n] = 0;        /* nullterminate */

      if (fputs(recvline, stdout) == EOF)

          fprintf(stderr, "fputs error");

}

先运行server,再启动client,client窗口可以正常返回server端传过来的数据。

考虑下面的情况,如果网络非常不好,server端在write成功后,数据经过了2s的时间才到达client端,这样对client端会造成什么影响呢?我们在write函数前加入sleep(2)来模拟上面说到的情况。实验结果发现client端的程序会在read函数中blook住,直到接受到server端传递过来的字符串后再打印。这说明read函数是同步的,如果socket关联的Buffer中没有数据,它会等待直至有数据的时候才返回。

另一个问题是write和read是否是成对的,也就是如果server端调用了n次的write,client端是否需要调用同等次(至少)的read来读取,每次read读取对应write写入的字符串。接着上面的例子做了下面的实验。

Server端代码修改如下:

   for ( ; ; )

    {

       connfd = accept(listenfd, (struct sockaddr *) NULL, NULL);

       if(connfd < 0)

       {

           fprintf(stderr, "accept error\n");

           return -1;

       }

 

        sleep(2);

       ticks = time(NULL);

       snprintf(buff, sizeof(buff), "%.24s\r\n", ctime(&ticks));

       write(connfd, buff, strlen(buff));

       write(connfd, "11111", 5);

       close(connfd);

}

在client端把每次read成功后都答应一个”success”字符串。

运行后发现,虽然server端调用了两次write函数,但是client端直调用了一次read就把所有字符串打印出来了。可以这么解释。当client端发现socket对应的buffer中有数据时便开始从中取数,由于server端是连续调用了两次write函数,client端在被通知可以从buffer中取数的时候,两次write的字符串均已经放入了buffer中,所以read只用了一次调用就把数据全都取出来了。这说明read和write完全没有对应关系,read只是单纯的从buffer中去数,而不管这些数是分了几次到来的。

又做了一个实验。在两次write之间加入了一条sleep语句,再次运行后,发现client端调用了两次read,打印的值和write一一对应。这也符合上面的结论:只要buffer有值,我就把它读出来并立即返回。

那么在那种情况下read返回的结果是0呢,毕竟如果没有收到任何数据的时候,read会block住。答案很简单,server端调用close函数时。

### RT-DETRv3 网络结构分析 RT-DETRv3 是一种基于 Transformer 的实时端到端目标检测算法,其核心在于通过引入分层密集正监督方法以及一系列创新性的训练策略,解决了传统 DETR 模型收敛慢和解码器训练不足的问题。以下是 RT-DETRv3 的主要网络结构特点: #### 1. **基于 CNN 的辅助分支** 为了增强编码器的特征表示能力,RT-DETRv3 引入了一个基于卷积神经网络 (CNN) 的辅助分支[^3]。这一分支提供了密集的监督信号,能够与原始解码器协同工作,从而提升整体性能。 ```python class AuxiliaryBranch(nn.Module): def __init__(self, in_channels, out_channels): super(AuxiliaryBranch, self).__init__() self.conv = nn.Conv2d(in_channels, out_channels, kernel_size=3, padding=1) self.bn = nn.BatchNorm2d(out_channels) def forward(self, x): return F.relu(self.bn(self.conv(x))) ``` 此部分的设计灵感来源于传统的 CNN 架构,例如 YOLO 系列中的 CSPNet 和 PAN 结构[^2],这些技术被用来优化特征提取效率并减少计算开销。 --- #### 2. **自注意力扰动学习策略** 为解决解码器训练不足的问题,RT-DETRv3 提出了一种名为 *self-att 扰动* 的新学习策略。这种策略通过对多个查询组中阳性样本的标签分配进行多样化处理,有效增加了阳例的数量,进而提高了模型的学习能力和泛化性能。 具体实现方式是在训练过程中动态调整注意力权重分布,确保更多的高质量查询可以与真实标注 (Ground Truth) 进行匹配。 --- #### 3. **共享权重解编码器分支** 除了上述改进外,RT-DETRv3 还引入了一个共享权重的解编码器分支,专门用于提供密集的正向监督信号。这一设计不仅简化了模型架构,还显著降低了参数量和推理时间,使其更适合实时应用需求。 ```python class SharedDecoderEncoder(nn.Module): def __init__(self, d_model, nhead, num_layers): super(SharedDecoderEncoder, self).__init__() decoder_layer = nn.TransformerDecoderLayer(d_model=d_model, nhead=nhead) self.decoder = nn.TransformerDecoder(decoder_layer, num_layers=num_layers) def forward(self, tgt, memory): return self.decoder(tgt=tgt, memory=memory) ``` 通过这种方式,RT-DETRv3 实现了高效的目标检测流程,在保持高精度的同时大幅缩短了推理延迟。 --- #### 4. **与其他模型的关系** 值得一提的是,RT-DETRv3 并未完全抛弃经典的 CNN 技术,而是将其与 Transformer 结合起来形成混合架构[^4]。例如,它采用了 YOLO 系列中的 RepNCSP 模块替代冗余的多尺度自注意力层,从而减少了不必要的计算负担。 此外,RT-DETRv3 还借鉴了 DETR 的一对一匹配策略,并在此基础上进行了优化,进一步提升了小目标检测的能力。 --- ### 总结 综上所述,RT-DETRv3 的网络结构主要包括以下几个关键组件:基于 CNN 的辅助分支、自注意力扰动学习策略、共享权重解编码器分支以及混合编码器设计。这些技术创新共同推动了实时目标检测领域的发展,使其在复杂场景下的表现更加出色。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值