CN108847997A

CN108847997A - 一种通过api接口进行通信的方法及其装置

Info

Publication number: CN108847997A
Application number: CN201810288946.0A
Authority: CN
Inventors: 王鹏
Original assignee: Zhengzhou Yunhai Information Technology Co Ltd
Current assignee: Zhengzhou Yunhai Information Technology Co Ltd
Priority date: 2018-04-03
Filing date: 2018-04-03
Publication date: 2018-11-20

Abstract

本申请提供了一种通过API接口进行通信的方法，包括：通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。因此，本申请实施实例提供的通过API接口进行通信的方法，能够实现异常日志的转存，操作简单，灵活性高。

Description

一种通过API接口进行通信的方法及其装置

技术领域

本申请涉及计算机通信领域，并且更具体地，涉及一种通过API接口进行通信的方法及其装置。

背景技术

很多企业的核心业务大都运行在服务器系上，一旦系统出现非预料的宕机，很可能造成数据出错甚至丢失，这种情况如果发生在金融和银行系统上，将会造成不可估量的损失。为此，有必要实时检测服务器的健康状态，包括风扇转速、CPU和主板的温度、核心电压、电源模块的状态等，进而及时预报各种可能出现的错误。系统管理软件(SystemManagemnet Software)就是为了实现这一功能的，它依赖于各个厂家的主板和模块的实现方式。为了统一不同厂家的实现方法，1998年Intel、Dell、HP、NEC共同提出了IPMI规范，用来监控温度、电压、风扇转速和实现远程控制。到2004年智能型平台管理接口(IntelligentPlatform Management Interface，IPMI)规范已经发展到了2.0颁布，并且广泛应用在各种服务器上，不同的厂家为了实现额外的功能，大都扩展了一些原始设备制造商(OriginalEquipment Manufacturer，OEM)的IPMI命令给用户。这就极大地方便了系统管理软件的设计和实现。

一个系统上可能有多个基板管理控制器(Baseboard Management Controller，BMC)，为基板管理控制器BMC，BMC上可以连接一些非智能的卡或者传感器sensor，这些器件和BMC以及BMC之间通过IPMB连接。和BMC通信的接口的包括系统管理总线(SystemManagement Bus，SMBus)、智能平台管理总线(Intelligent Platform Management BUS，Smbus)、(外设部件互连标准，peripheral component interconnect express，PCIE)、USB和低引脚数接口(low pin count，LPC)LPC。I2C在早期的系统上用得比较普遍，PCIE常用作KVM，而USB多用于固件升级，LPC接口最常见。BMC和主机之间的接口叫作SystemManagement Interface(简称system interface或si)。传统BMC的system interface包括：

KCS：最常用的接口，物理层基于LPC协议，实现了8742KCS interface。

SMIC：用在没有内建的KCS/LPC控制器的BMC上，有三个IO Port,可基于ASIC/FPGA实现。

BT：速度和性能最好的接口，需要握手，同样可基于ASIC/FPGA实现3个IO Port，可用于定制化的BMC上。

内核中IPMI驱动是分层实现的，最底层分别实现了基于Smbus、LPC的自动检测、事物处理、结果读取和清除的操作，并用这些函数初始化了抽象的System Interface对应的函数，从而屏蔽了底层硬件接口的区别。更上层的设备抽象和协议实现都是直接和SystemInterface直接交互的。简要的归纳如下：

ipmi_smbus.ko:实现对IPMI Management Controller基于Smbus直接访问的接口驱动；

ipmi_ssif.ko:在更早的内核版本里对应的名字就是ipmi_smbus.ko，支持通过Smbus接口发送、接收信息；

ipmi_si.ko:屏蔽了不同系统接口的驱动，支持KCS/SMIC/BT，除非host和BMC之间使用Smbus或者其他定制化的接口，否则都需要这一标准驱动；定义了probe BMC的三种方法：ACPI/SMBIOS(DMI)/PCI(class type)；

ipmi_msghandler.ko:内核实现的IPMI协议规范，它注册了IPMI驱动；

ipmi_devintf.ko:定义了/dev/ipmiX设备节点及对应的ioctl、open、release、fasync、poll、llseek操作函数集。其中ioctl的操作类型包括：

IPMICTL_SEND_COMMAND，IPMICTL_SEND_COMMAND，IPMICTL_RECEIVE_MSG和IPMICTL_RECEIVE_MSG_TRUNC。

ipmi_watchdog.ko：向用户空间提供一个标准的看门狗计时器；

ipmi_poweroff.ko:支持通过ipmi命令开关机的内核驱动。

虽然现有IPMI子系统提供了内核模块收发消息的API接口，ipmi_create_user、ipmi_request_supply_msgs、ipmi_destroy_user，但接口的使用上并不友好，有时候从使用者的角度考虑，它更想要的是常规的、易用的读写接口，比如异常日志转储功能模块，如果直接调用内核的API实现，除了要实现ipmi_user_hndl回调，ipmi_smi_msg和ipmi_recv_msg的done函数，还要在本地实现待发数据的封装和接收数据的解封装，不可避免的“污染”了文件原有的功能逻辑清晰度，使整体代码框架看起来不够优雅。

因此，亟需一种通过API接口进行通信的方法，能够实现异常日志的转存。

发明内容

本申请提供一种通过API接口进行通信的方法，能够实现异常日志的转存。

第一方面，本申请实施例提供一种通过API接口进行通信的方法，包括：通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

结合第一方面，在第一方面的第一种可能的实现方式中，所述KCS请求消息包括：第一网络功能字段，所述第一网络功能字段包括1个字节，用于表征所述目标数据在所述BMC中传输的第一级路由信息；第一命令字段，所述第一命令字段包括1个字节，所述第一命令字段用于指示所述目标数据中包括原始数据长度和压缩数据的长度信息，或者，所述第一命令字段用于指示所述目标数据种包括的实际传输数据；第一数据字段，所述第一数据字段包括N个字节，当所述第一命令字段用于指示所述目标数据包括原始数据长度和压缩数据的长度信息时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写，以及所述原始数据与压缩数据的长度；当所述第一命令字段用于指示所述目标数据包括的实际传输数据时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写、原始数据的长度、所述目标数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，N为正整数。

结合第一方面及其上述实现方式，在第一方面的第二种可能的实现方式中，所述KCS响应消息还用于携带所述BMC返回的请求数据，所述KCS响应消息包括：指示字段，所述指示字段用于表征所述BMC是否已经接收到所述KCS请求消息中携带的信息；第二网络功能字段，所述第二网络功能字段包括1个字节，用于表征所述KCS请求消息中向返回的所述请求数据的转发路径的第一级路由信息；第二命令字段，所述第二命令字段包括1个字节，所述第二命令字段用于指示所述请求数据中包括原始数据长度和压缩数据的长度信息，或者，所述第二命令字段用于指示所述请求数据种包括的实际传输数据；第二数据字段，所述第二数据字段包括M个字节，当所述第二命令字段用于指示所述请求数据包括的原始数据长度和压缩数据的长度信息时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及所述原始数据与压缩数据的长度；当所述第二命令字段用于指示所述请求数据包括的实际传输数据时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及原始数据的长度，所述请求数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，M为正整数。

结合第一方面及其上述实现方式，在第一方面的第三种可能的实现方式中，所述目标数据为所述网络设备的本地的异常日志。

结合第一方面及其上述实现方式，在第一方面的第四种可能的实现方式中，所述请求数据为所述BMC中存储的网络设备的异常日志。

第二方面，提供一种通信装置，包括：发送单元，所述发送单元用于通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；接收单元，所述接收单元用于接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

结合第二方面，在第二方面的第一种可能的实现方式中，所述KCS请求消息包括：第一网络功能字段，所述第一网络功能字段包括1个字节，用于表征所述目标数据在所述BMC中传输的第一级路由信息；第一命令字段，所述第一命令字段包括1个字节，所述第一命令字段用于指示所述目标数据中包括原始数据长度和压缩数据的长度信息，或者，所述第一命令字段用于指示所述目标数据种包括的实际传输数据；第一数据字段，所述第一数据字段包括N个字节，当所述第一命令字段用于指示所述目标数据包括原始数据长度和压缩数据的长度信息时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写，以及所述原始数据与压缩数据的长度；当所述第一命令字段用于指示所述目标数据包括的实际传输数据时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写、原始数据的长度、所述目标数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，N为正整数。

结合第二方面及其上述实现方式，在第二方面的第一种可能的实现方式中，所述KCS响应消息还用于携带所述BMC返回的请求数据，所述KCS响应消息包括：指示字段，所述指示字段用于表征所述BMC是否已经接收到所述KCS请求消息中携带的信息；第二网络功能字段，所述第二网络功能字段包括1个字节，用于表征所述KCS请求消息中向返回的所述请求数据的转发路径的第一级路由信息；第二命令字段，所述第二命令字段包括1个字节，所述第二命令字段用于指示所述请求数据中包括原始数据长度和压缩数据的长度信息，或者，所述第二命令字段用于指示所述请求数据种包括的实际传输数据；第二数据字段，所述第二数据字段包括M个字节，当所述第二命令字段用于指示所述请求数据包括的原始数据长度和压缩数据的长度信息时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及所述原始数据与压缩数据的长度；当所述第二命令字段用于指示所述请求数据包括的实际传输数据时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及原始数据的长度，所述请求数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，M为正整数。

结合第二方面及其上述实现方式，在第二方面的第三种可能的实现方式中，所述目标数据为所述网络设备的本地的异常日志。

结合第二方面及其上述实现方式，在第二方面的第四种可能的实现方式中，所述请求数据为所述BMC中存储的网络设备的异常日志。

因此，本申请实施实例提供的通过API接口进行通信的方法，能够实现异常日志的转存，操作简单，灵活性高。

附图说明

图1是本申请一个实施例的方法的示意性流程图。

图2是本申请一个实施例的请求消息的示意性结构图。

图3是本申请一个实施例的响应消息的示意性结构图。

图4是本申请一个装置的示意性结构图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

本申请实施例的设计原则是尽量使用内核现成的实现，为内核模块使用者提供简洁、易用的接口。第一层封装的基本读写接口内部借助ipmi_create_user、ipmi_request_supply_msgs、ipmi_destroy_user进行收发消息的组装、解析，借助完成量实现阻塞读写。考虑IPMI通信过程除了实际数据的交互外，还涉及命令的发送及反馈的处理，如果使用者直接使用这一层封装，就必须要了解不同的通信命令，设计上不够友好，因此，有必要做进一步封装，最终封装好的面向内核模块使用者的读写接口只包含与数据本身相关的参数。

为解决这个问题，本接口驱动在原有内核提供的API基础上，实现了面向“用户”的、友好的接口再封装，其他内核模块的使用者只需要调用熟悉的读写接口即可实现与BMC的数据收发。

图1示出了本申请一个实施例的方法的示意性流程图，如图1所示，该通过API接口进行通信的方法，包括：

步骤110，通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；

步骤120，接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

可选地，作为本申请一个实施例，所述KCS请求消息包括：第一网络功能字段，所述第一网络功能字段包括1个字节，用于表征所述目标数据在所述BMC中传输的第一级路由信息；第一命令字段，所述第一命令字段包括1个字节，所述第一命令字段用于指示所述目标数据中包括原始数据长度和压缩数据的长度信息，或者，所述第一命令字段用于指示所述目标数据种包括的实际传输数据；第一数据字段，所述第一数据字段包括N个字节，当所述第一命令字段用于指示所述目标数据包括原始数据长度和压缩数据的长度信息时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写，以及所述原始数据与压缩数据的长度；当所述第一命令字段用于指示所述目标数据包括的实际传输数据时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写、原始数据的长度、所述目标数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，N为正整数。

图2示出了本申请一个实施例的KCS请求消息的格式的示意图。如图2所示，其中第一网络功能字段为NetFn字段，BMC通过KCS接口接收到的消息中包含的第一级路由信息，系统侧发送的NetFn为偶数，BMC反馈的NetFn为加1的奇数。

第一命令字段为图中示出的Cmd，命令码，这里0xB2关联原始数据长度和压缩数据长度的读写(压缩长度有关的信息)，0xB3关联实际压缩数据的读写(实际数据的传输)。

第一数据字段为图中的Data，它占据了N个字节。

举例来说，一个KCS请求消息如下：

0x3a 0xb2 1FileOrignalSize FileCompressSize，其中“FileOrignalSizeFileCompressSize”分即为数据字段，1表示写，FileOrignalSize表示4字节原始数据长度，FileCompressSize表示4字节压缩后数据长度

可选地，作为本申请一个实施例，所述KCS响应消息还用于携带所述BMC返回的请求数据，所述KCS响应消息包括：指示字段，所述指示字段用于表征所述BMC是否已经接收到所述KCS请求消息中携带的信息；第二网络功能字段，所述第二网络功能字段包括1个字节，用于表征所述KCS请求消息中向返回的所述请求数据的转发路径的第一级路由信息；第二命令字段，所述第二命令字段包括1个字节，所述第二命令字段用于指示所述请求数据中包括原始数据长度和压缩数据的长度信息，或者，所述第二命令字段用于指示所述请求数据种包括的实际传输数据；第二数据字段，所述第二数据字段包括M个字节，当所述第二命令字段用于指示所述请求数据包括的原始数据长度和压缩数据的长度信息时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及所述原始数据与压缩数据的长度；当所述第二命令字段用于指示所述请求数据包括的实际传输数据时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及原始数据的长度，所述请求数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，M为正整数。

具体地，Completion Code是BMC反馈给系统侧的完成码，0表示消息传输成功，其他非0值表示特定异常。

图3示出了本申请一个实施例的KCS请求消息的格式的示意图。如图3所示，其中第二网络功能字段为NetFn/LUN字段，BMC通过KCS接口接收到的消息中包含的第一级路由信息，系统侧发送的NetFn为偶数，BMC反馈的NetFn为加1的奇数。

第二命令字段为图中示出的Cmd，命令码，这里0xB2关联原始数据长度和压缩数据长度的读写(压缩长度有关的信息)，0xB3关联实际压缩数据的读写(实际数据的传输)。

第二数据字段为图中的Data，它占据了N个字节。

举例来说，一个KCS响应消息如下：0x3a+1 0xb3CompleteCode FileBufferOffsetFileBufferlength Data，其中“CompleteCode FileBufferOffset FileBufferlengthData”部分也为数据字段，CompleteCode为1字节完成码，FileBufferOffset表示本次传输数据在整个数据中的4字节偏移，FileBufferlength表示本次传输数据的长度(1字节)，Data表示本次传输的数据本身(最长253-6字节)。

可选地，作为本申请一个实施例，所述目标数据为所述网络设备的本地的异常日志。

可选地，作为本申请一个实施例，所述请求数据为所述BMC中存储的网络设备的异常日志。

具体地，实现上述方法的结构体如下：

相关结构体

typedef struct_globals{

unsigned char io_dir；

unsigned char cmd；

unsigned char*buf；

unsigned int times；

unsigned int reallen；

unsigned char completecode；

}globals；

自定义的通信协议中，一次消息传输最大255-6字节，所以在接收大于255-6字节的数据时，需要有一个全局的buffer来存放分多次读到的数据，最后再一起返回给请求方。这里，io_dir表示读写方向，0代表读，1代表写；cmd表示具体命令码；*buf是全局buffer指针；times代表需要发起的读操作次数；reallen代表实际接收到的总的数据量；completecode是BMC返回的完成码。

typedef struct requestB3{

unsigned int FileBufferOffset；

unsigned char FileBufferlength；

unsigned char*data；

}__attribute__((packed))requestB3_t；

0xB3写消息格式封装，FileBufferOffset代表本次发送的数据在整体数据缓冲中的偏移；FileBufferlength代表本次发送的数据长度；*data实际数据指针。

typedef struct responseB3{

unsigned int FileBufferOffset；

unsigned char FileBufferlength；

unsigned char*data；

}__attribute__((packed))responseB3_t；

0xB3读消息格式封装，FileBufferOffset代表BMC本次传回的数据在其内部数据缓冲中的偏移；FileBufferlength代表BMC本次传回的数据长度；*data存放实际传回的数据。

具体来说，从系统侧写数据到BMC的主要流程步骤总结为：1.发送WRITE_START控制码到命令寄存器，启动传输；2.写数据(NetFn、Command、Data)到Data_In寄存器；3.发送WRITE_END控制码到命令寄存器，随后发送最后一字节数据。

另一方面，从BMC读数据到系统侧的主要流程步骤总结：1.当OBF置位时，读Data_Out寄存器；2.发送READ控制码请求下一字节数据；3.IBF等于0时，如果处于READ_STATE，则重复前两个步骤。

进一步地，测试用例片段如下：

unsigned char s[32]；

unsigned char back_buf[32]；

int reallen＝0；

int i；

struct send_data log_send；

struct recv_data log_recv；

s[0]＝0xbe；

s[1]＝0xef；

log_send.originlen＝2；

log_send.compresslen＝2；

log_send.sendbuf＝s；

write_data(&log_send,&reallen)；

log_recv.recvbuf＝back_buf；

log_recv.maxrecvlen＝1024*1024；

read_data(&log_recv,&reallen)；

printk("originlen＝％u,compresslen＝％u\n",log_recv.originlen,log_recv.compresslen)；

for(i＝0；i<4；i++)

printk("data[％d]:0x％x\n",i,back_buf[i])；

本驱动借助内核现有设施，通过两层封装，为内核中的使用者提供了友好、易用的读写接口。第一层封装实现数据帧级别的读写，包括数据帧的组织和解析，第二层封装进一步屏蔽通信协议的细节，实现数据本身级别的读写封装。

图4示出了本申请一个实施例的通信装置的示意图结构框图，如图4所示，该装置400包括：

发送单元410，所述发送单元410用于通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；

接收单元420，所述接收单元420用于接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者第二设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应所述以权利要求的保护范围为准。

Claims

1.一种通过API接口进行通信的方法，其特征在于，包括：

通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；

接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

2.根据权利要求1所述的方法，其特征在于，所述KCS请求消息包括：

第一网络功能字段，所述第一网络功能字段包括1个字节，用于表征所述目标数据在所述BMC中传输的第一级路由信息；

第一命令字段，所述第一命令字段包括1个字节，所述第一命令字段用于指示所述目标数据中包括原始数据长度和压缩数据的长度信息，或者，所述第一命令字段用于指示所述目标数据种包括的实际传输数据；

第一数据字段，所述第一数据字段包括N个字节，当所述第一命令字段用于指示所述目标数据包括原始数据长度和压缩数据的长度信息时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写，以及所述原始数据与压缩数据的长度；

当所述第一命令字段用于指示所述目标数据包括的实际传输数据时，所述第一数据字段与所述第一命令字段共同指示所述目标数据的读或写、原始数据的长度、所述目标数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，N为正整数。

3.根据权利要求1或2所述的方法，其特征在于，所述KCS响应消息还用于携带所述BMC返回的请求数据，所述KCS响应消息包括：

指示字段，所述指示字段用于表征所述BMC是否已经接收到所述KCS请求消息中携带的信息；

第二网络功能字段，所述第二网络功能字段包括1个字节，用于表征所述KCS请求消息中向返回的所述请求数据的转发路径的第一级路由信息；

第二命令字段，所述第二命令字段包括1个字节，所述第二命令字段用于指示所述请求数据中包括原始数据长度和压缩数据的长度信息，或者，所述第二命令字段用于指示所述请求数据种包括的实际传输数据；

第二数据字段，所述第二数据字段包括M个字节，当所述第二命令字段用于指示所述请求数据包括的原始数据长度和压缩数据的长度信息时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及所述原始数据与压缩数据的长度；

当所述第二命令字段用于指示所述请求数据包括的实际传输数据时，所述第二数据字段与所述第二命令字段共同指示所述请求数据的读或写，以及原始数据的长度，所述请求数据中实际传输数据和所述实际传输数据在所述原始数据中的位置偏移量，其中，M为正整数。

4.根据权利要求1至3中任一项所述的方法，其特征在于，所述目标数据为所述网络设备的本地的异常日志。

5.根据权利要求3中所述的方法，其特征在于，所述请求数据为所述BMC中存储的网络设备的异常日志。

6.一种通信装置，其特征在于，包括：

发送单元，所述发送单元用于通过API接口，使用KCS请求消息向网络设备的BMC发送目标数据；

接收单元，所述接收单元用于接收所述BMC返回的KCS响应消息，所述KCS响应消息至少用于表征所述BMC接收到所述目标数据。

7.根据权利要求6所述的装置，其特征在于，所述KCS请求消息包括：

第一命令字段，所述第一命令字段包括1个字节，所述第一命令字段用于指示所述目标数据中包括原始数据长度和压缩数据的长度信息，或者，所述第一命令字段用于指示所述目标数据种包括的实际传输数据。

8.根据权利要求6或7所述的装置，其特征在于，所述KCS响应消息还用于携带所述BMC返回的请求数据，所述KCS响应消息包括：

9.根据权利要求6至8中任一项所述的装置，其特征在于，所述目标数据为所述网络设备的本地的异常日志。

10.根据权利要求8中所述的装置，其特征在于，所述请求数据为所述BMC中存储的网络设备的异常日志。