TCP/IP 网络编程
互联网上的每个接口必须有一个唯一的`Internet`地址(也成为IP地址)。
IP地址长`32 bit`。
`Internet`地址并不采用平面形式的地址控件，如 1、2、3等。IP地址具有一定的结构，五类不同的互联网地址格式如图：
![[Picture/IP地址.png]]
数据包分层
![[Picture/IP分层.png]]
>端口号：
>FTP服务的TCP端口号都是21
>每个Telnet服务器的TCP端口号都是23
>每个TFTP(简单文件传送协议)服务器的UDP端口号都是69
>任何TCP/IP实现所提供的服务都用知名的`1~1023`之间的端口号
>端口范围 `0~65535` 16bit
大端字节序（Big-endian）和小端字节序（Little-endian）是计算机存储多字节数据的两种不同的方式，主要涉及到字节的顺序。这两种方式的差异在于多字节数据的最高位字节和最低位字节在内存中的存放位置。
1. **大端字节序 (Big-endian)**:
- 最高位字节存放在最低内存地址上，而最低位字节存放在最高内存地址上。
- 例如，一个 32 位的数值 0x12345678 在内存中的布局（从低地址到高地址）为：12 34 56 78。
2. **小端字节序 (Little-endian)**:
- 最低位字节存放在最低内存地址上，而最高位字节存放在最高内存地址上。
- 与上述的例子相比，0x12345678 在内存中的布局为：78 56 34 12。
这两种方式的选择会取决于处理器架构。例如，Intel x86 架构采用小端字节序，而许多 RISC 架构（如 SPARC、Motorola 68k）采用大端字节序。
为何需要知道字节序？
- 在进行网络通信时，字节序是非常重要的。网络协议，如 TCP/IP，规定数据在网络上应使用大端字节序（也被称为网络字节序）。
- 如果两台计算机采用不同的字节序，那么在发送和接收数据时就需要进行字节序的转换。
- 在跨平台开发中，了解字节序也是很重要的，尤其是在处理二进制数据时。
与你的目标相关，C++编程中经常会遇到字节序问题，尤其是在进行底层编程、操作系统开发或网络编程时。而在UE（即Unreal Engine，我猜测你指的是这个）开发中，也可能会涉及到跨平台的问题，这时候对字节序有深入的了解是非常有用的。
最后，为了解释中英文含义的区别：
- 大端字节序: English - "Big-endian"
- 小端字节序: English - "Little-endian"
[[TCP连接]]
开启复制。
`bReplication = true`;
默认情况下，角色是开启网络复制的
在关卡蓝图中判断是否是权威
![[Picture/Switch-Has-Authority.png]]
# UE的网络模块
Replication
1. Actor Replication
2. Property Replication
3. Component Replication
Session 会话
多人游戏：游戏实例在独立的两台主机中运行，
由于玩家不断输入指令，服务器需要将这些信息通过网络传输给另一个游戏实例。
服务器上运行的游戏实例是最正确的版本，权威(Authority)
UE中网络信息传输的方式
1. Replication:信息从服务器同步到客户端
Actor以及派生类支持Replication
1. Rep_Notify
2. RPC
Property Replication
1. UPROPERTY(Replicated)
2. GetLifetimeReplicatedProps 重写
3. 内部注册同步变量 DOREPLIFTIME(类名，变量名)
在Unreal Engine中，远程过程调用（RPC）提供了一种在网络环境中调用函数的机制。RPCs通常用于确保某些操作（如玩家的动作或交互）在权威服务器或客户端上执行，并确保相应的信息在必要时被复制到其他机器。
有三种主要的RPC类型，它们是：
1. **Run On Server**:
- **描述**: 这种RPC在客户端上被调用，但实际上在服务器上执行。
- **使用场景**: 客户端想通知服务器它希望执行某个操作。例如，玩家想要移动、跳跃、交互等。
- **注意事项**: 为了安全起见，`Run On Server` RPCs需要验证函数（`_Validate`函数）来确认客户端请求的操作是否合法。
2. **Multicast**:
- **描述**: 这种RPC在服务器上被调用，并在所有连接的客户端上执行。
- **使用场景**: 当服务器想要通知所有客户端某个事件发生时。例如，玩家完成了一个任务，所有其他玩家都应该看到一个通知。
- **注意事项**: `Multicast` RPCs应该小心使用，因为它们会发送到所有客户端，可能会导致不必要的网络流量。
3. **Run On Owning Client**:
- **描述**: 这种RPC在服务器上被调用，但只在拥有该特定对象的客户端上执行。
- **使用场景**: 服务器想要给某个玩家发送一个专属于他的消息或事件。例如，只有某个玩家完成了任务，所以只有他应该收到奖励通知。
- **注意事项**: 要确保你知道哪个客户端是对象的“拥有者”，因为只有拥有者才会执行这个RPC。
确实，当你在Unreal Engine的蓝图编辑器中创建RPC时，你会看到一个“可靠”(Reliable)选项。这个选项决定了RPC是可靠的还是不可靠的，这与网络通信中的概念相对应。
1. **可靠 (Reliable)**:
- 如果一个RPC被标记为可靠，那么它会确保至少被接收并执行一次。
- 这是有代价的，因为网络系统需要跟踪这些调用，确保它们被正确地传递和确认。因此，如果频繁地调用大量的可靠RPC，可能会导致网络拥堵和延迟。
2. **不可靠 (Unreliable)**:
- 如果一个RPC被标记为不可靠，那么它可能会丢失，并且不会有任何重试机制。
- 适用于那些不需要100%传输保证的信息。例如，一个玩家的实时位置更新在快速移动时可能不需要每次都被完美传输。
**进一步拓展三个RPC类型**：
1. **Run On Server**:
- 当客户端想要通知服务器一个特定的行为或决策时使用。
- 例如，当玩家尝试开火、使用物品或做出其他主要游戏决策时。
- 在某些情况下，可以设置为不可靠，例如，快速连续的小动作。
2. **Multicast**:
- 当服务器需要告诉所有客户端某件事情发生时使用。
- 通常用于全局事件或状态变化，例如天气变化、全局公告等。
- 考虑到所有客户端都需要收到的重要性，这类RPCs通常设置为可靠。但在某些场景，例如频繁的、不太重要的视觉特效，可以设置为不可靠。
3. **Run On Owning Client**:
- 当服务器需要告诉某个特定的客户端某件事情时使用。
- 例如，一个玩家获得了一项新的任务，或者他们的角色受到了伤害。
- 这种情况下，大部分时间都会设置为可靠，因为这类信息通常对玩家来说很重要。
总的来说，选择是否使用“可靠”应该基于你的具体需求。如果某个事件或信息对游戏的运行至关重要，那么它应该是可靠的。但是，如果它只是影响某些不太重要的视觉或音频效果，或者频繁地发生，那么可能更适合设为不可靠。
RPC 是“Remote Procedure Call”的缩写，中文意为“远程过程调用”。这是一个计算机通信协议，允许运行在一个地址空间的程序调用运行在另一个地址空间的程序中的子程序或函数。这两个地址空间可能位于同一台计算机上，也可能位于网络上的两台不同计算机上。
在游戏开发，特别是在多人在线游戏的上下文中，RPC常常指的是允许在一个机器（例如客户端）上的代码请求另一个机器（例如服务器）执行某个操作。
**在Unreal Engine中的RPC**:
Unreal Engine针对网络游戏开发提供了专门的RPC系统。这在多人游戏中是非常重要的，尤其是在需要在客户端和服务器之间同步或传输信息时。例如，当一个玩家在其客户端上执行一个动作（如跳跃或射击），这个动作可能需要通过一个RPC通知服务器。
**为什么使用RPC**:
1. **同步**: 在多人游戏中，确保所有玩家都看到相同的游戏状态是至关重要的。RPC允许服务器和客户端之间进行这种同步。
2. **安全性**: 在多人游戏中，权威通常由服务器持有，这是为了避免作弊。客户端可能会发出RPC请求，但最终的决策（例如，是否允许玩家的角色射击）由服务器做出。
3. **性能**: 通过有效地使用RPC，开发者可以优化网络流量，确保只传输必要的信息。
总的来说，RPC是网络编程和特定于网络的游戏开发中的核心概念。它提供了一种有效、安全的方式，使在不同机器上运行的代码能够互相通信和交互。