socket 编程入门教程(五)UDP原理:1、设计UDP server类

socket 编程入门教程(五)UDP原理:1、设计UDP server类

人们通常用电话连线来说明TCP协议,而UDP协议,则常常用邮递来做比喻。与TCP有连接的信息传输方式不同,UDP协议被认为是对底层IP协议简单的扩展:协议并不保证每个数据包都会到达目的地,也不保证到达的顺序,而仅仅就是“尽力”的发送每一个数据包。我在这篇教程中有时候使用“数据包”有时候使用“数据报”,广义的说,这两个词意思类似,有代表一个有大小边缘的数据块。但是,用“数据包”的时候,我想强调的是这个数据块中所传送的数据部分;而“数据报”则更强调在数据块中对这段数据的信息和说明部分,比如IP首部,TCP和UDP首部,TCP和UDP报文段这些信息。TCP协议通过同步验证实现了TCP层面上的“数据流”传送,而下层的IP协议,依然是数据报形式的传送,这个我们在前面已经描述过,比如连接握手和断开握手,实际上都是发送的TCP数据报(TCP格式的IP数据报)。UDP格式的IP数据报为IP数据报指定了UDP端口,从而使这样的IP数据报的目的地能够精确到应用程序——没有端口指定的IP数据报目的地只能精确到具有IP地址的主机。另外,与TCP的无边缘保证相反,UDP数据包是有大小的,而其最大限制也即是IP数据包大小的最大限制:65,507字节(这里需要说明两点:1、IP数据包的理论最大值为2^16 – 1,即65,535字节,UDP数据报因为要包含UDP首部的信息,所以比这个值小一点;2、因为MTU的存在,实际传输中的IP数据包会被分封到1500字节以下。)
因为UDP是无连接的,就像一个邮筒,可以接受来自任何人的邮件;也可以发送给任何人的邮件。而每一次接受,都会得到来向的地址;每一次发送,也必须指明去向的地址。我们设计一个类,分别以lastfromSockAddr和destinationSockAddr表示最后一次来向的地址以及(下一次发送的)目的地地址。需要指出的是,因为防火墙的普遍存在,最后一次来向地址变得极其重要!这一点我们将在后面的讨论中看到。

class UDPServerSock: public BaseSock {

private:
    sockaddr_in serverSockAddr;
protected:
    mutable sockaddr_in lastfromSockAddr;
    sockaddr_in destinationSockAddr;
    
char* preBuffer;
    
int preBufferSize;
    mutable 
int preReceivedLength;
public:
    
explicit UDPServerSock(
            unsigned 
short server_port,
            
int pre_buffer_size = 32);
    
virtual ~UDPServerSock();
    
void UDPSetDest(const char* dest_IP,
            
const unsigned short& dest_port);
    
void UDPSetDest(const sockaddr_in& dest_sock_addr);
    
int UDPReceive() const;
    
int UDPSendtoDest(const char* send_data,
            
const int& data_length) const;
};

我们把最后一次来向地址以及预接收缓存中的收到的数据长度设置成mutable是因为我们希望接收UDPReceive()这个方法看起来是不改变对象的。每一次接收,实际上都会刷新lastfromSockAddr,而作为服务器,往往也是通过lastfromSockAddr去决定destinationSockAddr的。

UDPServerSock::UDPServerSock(unsigned short server_port,
                             
int pre_buffer_size):
preBufferSize(pre_buffer_size), preReceivedLength(
0)
{

    preBuffer 
= new char[preBufferSize];
    memset(
&serverSockAddr, 0sizeof(serverSockAddr));
    memset(
&lastfromSockAddr, 0sizeof(lastfromSockAddr));
    memset(
&destinationSockAddr, 0sizeof(destinationSockAddr));

    serverSockAddr.sin_family = AF_INET;
    serverSockAddr.sin_addr.s_addr 
= htonl(INADDR_ANY);
    serverSockAddr.sin_port 
= htons(server_port);
    

    sockFD = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
    
if (sockFD < 0) {

        sockClass::error_info(
sock() failed.);
    }

    if (bind(    sockFD,
                (sockaddr
*)&serverSockAddr,
                
sizeof(serverSockAddr)) < 0) {

        sockClass::error_info(
bind() failed.);
    }
}

UDPServerSock::~UDPServerSock()
{

    delete [] preBuffer;
    close(sockFD);
}

构造函数依然使用socket()建立sockFD,然后通过bind()将本机的SockAddr(主要是指定了端口)绑定到这个sockFD上。
我们重载了UDPSetDest()这个方法,可以有两种方式去指定目标地址destinationSockAddr——既可以指定IP地址和端口,也可以直接赋值以sockaddr_in结构。

void UDPServerSock::UDPSetDest(const char* dest_IP,
                               
const unsigned short& dest_port)
{

    destinationSockAddr.sin_family 
= AF_INET;
    destinationSockAddr.sin_addr.s_addr 
= inet_addr(dest_IP);
    destinationSockAddr.sin_port 
= htons(dest_port);
}

void UDPServerSock::UDPSetDest(const sockaddr_in& dest_sock_addr)
{

    destinationSockAddr.sin_family 
= dest_sock_addr.sin_family;
    destinationSockAddr.sin_addr.s_addr 
= dest_sock_addr.sin_addr.s_addr;
    destinationSockAddr.sin_port 
= dest_sock_addr.sin_port;
}

最后是接收和发送。我们知道TCP里面recv()返回0表示连接正常断开,而UDP里面,则仅仅就是表示收到0字节的数据包。可见,数据大小为0,并不代表数据包为空,因为这个数据包实际也是一个数据报,包含着TCP数据报的各种必要信息。

int UDPServerSock::UDPReceive() const
{

    socklen_t
 from_add_len = sizeof(lastfromSockAddr); //use int in win32
    preReceivedLength 
= recvfrom(    sockFD,
                                    preBuffer,
                                    preBufferSize,
                                    
0,
                                    (sockaddr
*)&lastfromSockAddr,
                                    
&from_add_len);
    
if ( preReceivedLength < 0) {

        sockClass::error_info(
recv() failed.);
    }

    return preReceivedLength;
}

int UDPServerSock::UDPSendtoDest(const char* send_data,
                                 
const int& data_length) const
{

    
int send_message_size = sendto(    sockFD,
                                    send_data,
                                    data_length,
                                    
0,
                                    (sockaddr
*)&destinationSockAddr,
                                    
sizeof(destinationSockAddr));
    
if (send_message_size < 0) {

        sockClass::error_info(
send() failed.);
    }
    
if (send_message_size != data_length) {

        sockClass::error_info(
            
send() sent a different number of bytes than expected.);
    }
    
return send_message_size;
}

转载于:https://my.oschina.net/GeorgeSu/blog/264205

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/109831.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • leetcode-403. 青蛙过河(动态规划|记忆化搜索)[通俗易懂]

    leetcode-403. 青蛙过河(动态规划|记忆化搜索)[通俗易懂]一只青蛙想要过河。 假定河流被等分为若干个单元格,并且在每一个单元格内都有可能放有一块石子(也有可能没有)。 青蛙可以跳上石子,但是不可以跳入水中。给你石子的位置列表 stones(用单元格序号 升序 表示), 请判定青蛙能否成功过河(即能否在最后一步跳至最后一块石子上)。开始时, 青蛙默认已站在第一块石子上,并可以假定它第一步只能跳跃一个单位(即只能从单元格 1 跳至单元格 2 )。如果青蛙上一步跳跃了 k 个单位,那么它接下来的跳跃距离只能选择为 k – 1、k 或 k + 1 个单位。 另请注意

  • 图的存储及遍历 深度遍历和广度遍历 C++代码实现

    写这个程序给我的感觉就是乱,思路不是很清晰,遍历的逻辑关系还掌握的不是很熟,只是大概知道是这么回事,但是让自己去写的话,可能就写不出来了!还是要加大对遍历的熟悉程度才行啊!PS:另外推荐一个让大家真

    2021年12月25日
  • CSS中 RGB颜色查询对照表

    CSS中 RGB颜色查询对照表颜色代码表Ⅰ #000000 #2F0000 #600030 #460046 #28004D #272727 #4D0000 #820041 #5E005E #3A006F #3C3C3C #600000 #9F0050 #750075 #4B0091

  • 万物互联时代,警惕黑客“帮凶”

    万物互联时代,警惕黑客“帮凶”

  • vue详解_vuex getters

    vue详解_vuex gettersVuex是做什么的?官方解释:Vuex是一个专为Vue.js应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态,并以相应的规则保证状态以一种可预测的方式发生变化。Vuex

  • 什么是雪崩效应?雪崩效应常见场景及应对策略

    什么是雪崩效应?雪崩效应常见场景及应对策略一、什么是雪崩效应分布式系统环境下,服务间类似依赖非常常见,一个业务调用通常依赖多个基础服务。如下图,对于同步调用,当会员服务不可用时,订单服务请求线程被阻塞,当有大批量请求调用会员服务时,最终可能导致整个会员服务资源耗尽,无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递,这种现象被称为雪崩效应。​二、雪崩效应常见场景硬件故障:如剔除坏盘抖动,服务器宕机,网络抖动,机房断电,光纤被挖断等;流量激增:如异常流量,重试加大流量等;缓存穿透:短时间内大量缓存失效时,大

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号