CN112565267B - 向前兼容元素增量变化的数据传输方法及*** - Google Patents
向前兼容元素增量变化的数据传输方法及*** Download PDFInfo
- Publication number
- CN112565267B CN112565267B CN202011417771.2A CN202011417771A CN112565267B CN 112565267 B CN112565267 B CN 112565267B CN 202011417771 A CN202011417771 A CN 202011417771A CN 112565267 B CN112565267 B CN 112565267B
- Authority
- CN
- China
- Prior art keywords
- field
- information
- serialization
- version
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/06—Notations for structuring of protocol data, e.g. abstract syntax notation one [ASN.1]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种向前兼容元素增量变化的二进制序列化结构、方法及***，结构体列表在序列化时按照结构体中的定义字段进行平铺序列化，在序列化结构体列表时，在每个元素结构体的前面序列该原元素结构体的长度，在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址。本发明通过增加元素长度字段，反序列化时根据长度字段定位元素的起止地址，从而避免的服务器的新老版本兼容，实现的列表结构体增量变化后向前兼容。
Description
技术领域
本发明涉及互联网通信领域，具体涉及一种网络信息交互的数据结构以及采用这种结构进行信息传输的方法及***。
背景技术
在服务器开发中，为了性能，请求和回复的包都是通过二进制序列化方式来进行传输的。而在传输列表结构体请求或者回复时，都会经常遇到后续请求或回复中列表结构体增量变化的情况，通常的情况下，结构体列表在序列化时都是按照结构体中的定义字段进行平铺序列化，在结构增加字段变化的情况下就做不到向前兼容，通常需要根据业务的版本号来进行新老版本区别，根据不同的版本发送不同的新老结构体，若是不根据版本发送不同的结构体，会出现老版本客户端无法正确解析数据的情况。
发明内容
本发明要解决的技术问题是：如何使旧版本的客户端正确解析具有增量数据的新版本二进制序列化结构。
一种向前兼容元素增量变化的数据传输方法，将数据转化为二进制序列化结构体列表进行传输，结构体列表在序列化时按照结构体中的定义字段进行平铺序列化，在序列化结构体列表时，在每个元素结构体的前面序列化该原元素结构体的长度，在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址，在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址。
当新版本的定义字段相较于旧版本的定义字段存在增量时，按照最新版本定义的字段进行序列化结构体列表，每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本反序列化后使用元素的所有信息，旧版本反序列化之后不使用增量信息只使用旧版本定义的字段信息。
结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段定位每个元素起止地址，进行反序列化获取元素信息，若采用旧版本反序列化则不使用新增的元素信息。
结构体列表的前四个字节代表用户ID，第五和第六字节代表元素数量，第七和第八字节代表第一个元素的长度，之后是是第一个元素的信息，依次类推排布剩余元素的长度和元素信息。
一种向前兼容元素增量变化的数据传输***，包括服务器和客户端，两者请求和回复的包通过二进制序列化方式来进行传输，服务器在序列化结构体列表的每个元素时在前面序列该结构体元素序列化后的长度，客户端在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址。
当服务器更新为新版本而客户端未及时更新时，服务器按照最新版本定义的字段进行序列化结构体列表，每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本客户端反序列化后使用元素的所有信息，旧版本客户端反序列化之后不使用增量信息只使用旧版本定义的字段信息。
本***用于网络社交服务，结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段反序列化各个元素的信息，若采用旧版本客户端反序列化则不使用新增的元素信息。
所述元素信息包含用户的网络好友身份特征。
本发明的有益效果是：本发明通过增加元素长度字段，反序列化时根据长度字段定位元素的起止地址，从而避免的服务器的新老版本兼容，实现的列表结构体增量变化后向前兼容，采用本发明可以兼容不同的版本的应用场景，从服务端获取到的一条数据信息可以适应于新旧版本的客户端，不同版本的客户端可以正确解析存在数据增量的新版本数据。
附图说明
图1是本发明序列化和反序列化时对不同元素结构体的位置定位过程。
图2为本发明的二进制序列化结构。
图3为本发明所对应的***结构图。
具体实施方式
以常见的拉取好友列表的回复来说明结构体列表的结构体增量变化带来的新老版本兼容问题。在一般的社交服务器中，都有拉取好友详情列表的请求服务，请求的输入参数是用户ID，请求回复的输出参数是好友详情的列表，例如好友详情的结构体STR_FRIEND_INFO定义如下(其中uint32_t为32无符号整型，uint8_t为8位无符号整型)：
| 字段名 | 类型 | 解释 |
| friend_id | uint32_t | 好友标识ID |
| gender | uint8_t | 好友性别 |
| age | uint8_t | 好友年龄 |
假设好友请求回复的内存标识结构体为T_USER_FRIEND_LIST_RESPONSE，定义如下：
| 字段名 | 类型 | 解释 |
| user_id | uint32_t | 请求的用户ID |
| friend_list | vector<STR_FRIEND_INFO> | 好友列表 |
则有2个好友的回复的一般的序列化后的二进制数据表示为（其中list_cnt为friend_list的元素个数）:
| user_id | list_cnt | friend_id | gender | age | friend_id | gender | age |
现在假设user_id为1000000的用户有2个好友，好友信息分别为{1000001, 1,18}, {1000002, 2, 20} (其中性别1表示男，2表示女)。该用户想服务器请求好友列表时，服务器回复的序列化后的二进制数据具体如下（采用大端字节序存储，内存地址从左到右，从上到下是升序的排列，只显示具体的业务数据，省略了相应的包头数据，下表中的第一列表示本行内存的其实地址，后面的一个单元格表示一个字节）：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 |
客户端在收到以上二进制数据后按照服务器序列化的顺序进行反序列化，将二进制数据转化为内存的数据结构体，具体的反序列化流程如下：
反序列化user_id
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 |
将二进制数据中黑体部分的四个字节的内存反序列化为user_id，这四个字节的内容16进制表示为0x000F4240，转换为10进制就是1000000，反序列化出请求的用户ID为1000000。
反序列化好友列表的成员个数
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 |
将二进制数据中的黑体部分的两个字节的内存反序列化为好友列表的成员个数list_cnt,这两个字节的内容16进制的表示为0x0002，就是10进制中的2，表示有两个好友。
反序列化好友
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 |
将二进制数据中的连续的黑体字部分的内存反序列化为第一个好友的信息，第二排前4个字节的内容16进制为0x000F4241,反序列化为friend_id为1000001，第5个字节返回为话为性别1，第6个字节内存反序列化为年龄18。接着将剩下的第三排6个字节按照刚才的顺序反序列化出用户的第二个好友信息。最后客户端反序列化出来的信息跟服务器序列化前的信息完全一致。
如果现在新需求的出现，需要增加好友的身高字段，则结构体STR_FRIEND_INFO定义如下：
| 字段名 | 类型 | 解释 |
| friend_id | uint32_t | 好友标识ID |
| gender | uint8_t | 好友性别 |
| age | uint8_t | 好友年龄 |
| height | uint8_t | 好友身高 |
则2个好友的新回复的序列化后的二进制数据表示为：
| user_id | list_cnt | friend_id | gender | age | height | friend_id | gender | Age | height |
假设用户1000000的两个好友在增加身高后的信息为{1000001, 1, 18, 175},{1000002, 2, 20, 165}。如果服务器不做新老版本兼容，统一使用新版本的序列化的二进制数据，则服务器发送给刚那个用户的回复的二进制数据具体如下：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 10101111 | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 |
| 0x12 | 00010100 | 10100101 |
则老版本客户端在收到新格式的好友列表回复时，会按照老的序列化的二进制格式进行反序列化，则老版本客户端在反序列化出第一个好友的friend_id, gender, age信息后就会把后面紧着的数据当成第二个好友信息的开始，会从如下第三排黑体部分开始反序列化第二个好友的friend_id：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00001111 | 01000010 | 01000001 | 00000001 | 00010010 |
| 0xc | 10101111 | 00000000 | 00001111 | 01000010 | 01000010 | 00000010 |
| 0x12 | 00010100 | 10100101 |
这样解析出来的friend_id为2936016706（16进制为0xAF000F42），接着反序列化出来的gender和age分别为66和2，跟服务器的第二个好友的信息完全不对。这就是一般情况下的结构体列表的序列化方式不具备向前兼容性而导致的问题，需要服务器使用版本号来进行控制，对不同版本推送不同格式的序列化包。而服务器会随着类似的兼容性问题而维护很多版本号，导致可阅读性和可维护性降低。
为此，本发明一种向前兼容元素增量变化的数据传输方法，将数据转化为二进制序列化结构体列表进行传输，如图1，结构体列表在序列化时按照结构体中的定义字段进行平铺序列化，在序列化结构体列表的每个元素时在前面序列该结构体元素序列化后的长度，在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址（每个元素序列化开始的地址是指图1中白色段的开始地址，而每个元素结构前面的代表该元素体长度的字段是等长的，所以直接相加即可得到下一个元素信息的起始地址）。当新版本的定义字段相较于旧版本的定义字段存在增量时，按照最新版本定义的字段进行序列化结构体列表，每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本反序列化后使用元素的所有信息，旧版本反序列化之后不使用增量信息只使用旧版本定义的字段信息。
如图2，结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段定位每个元素起止地址，进行反序列化获取元素信息，若采用旧版本反序列化则不使用新增的元素信息。
每个结构体元素前面是代表该结构体元素序列化长度的字段。
结构体列表的前四个字节代表用户ID，第五和第六字节代表元素数量，第七和第八字节代表第一个元素的长度，之后是是第一个元素的信息，依次类推排布剩余元素的长度和元素信息。
一种向前兼容元素增量变化的数据传输***，如图3所示，包括服务器和客户端，两者请求和回复的包通过二进制序列化方式来进行传输，序列化的方法如图1，服务器在序列化结构体列表的每个元素时在前面序列该结构体元素序列化后的长度，客户端在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址。
如图3所示，当服务器更新为新版本而客户端未及时更新时，服务器同时向新版本的客户端和旧版本客户端提供数据服务，收到请求后服务器按照最新版本定义的字段进行序列化结构体列表（如图2），每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本客户端反序列化后使用元素的所有信息，旧版本客户端反序列化之后不使用增量信息只使用旧版本定义的字段信息。
进一步的，本***用于网络社交服务，结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段反序列化各个元素的信息，若采用旧版本客户端反序列化则不使用新增的元素信息。所述元素信息包含用户的网络好友身份特征。
下面以具体的使用实例来说明本发明实现过程及数据存储的方式：
还是以上述的好友回复为例进行说明，则好友结构体STR_FRIEND_INFO变化前的回复包序列化后的二进制数据如下：
| user_id | list_cnt | ele_sz | friend_id | gender | age | ele_sz | friend_id | gender | age |
其中ele_sz是列表中每个好友信息序列化后的字节大小，在此例中其长度为uint16_t。而好友结构体增加height字段变化后的回复包的序列化后的二进制数据如下：
| user_id | list_cnt | ele_sz | friend_id | gender | Age |
| height | ele_sz | friend_id | gender | age | Height |
则服务器回复给用户1000000的变化前的好友列表序列化后的二进制数据具体如下：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000110 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 00000000 | 00000110 | 00000000 | 00001111 |
| 0x12 | 01000010 | 01000010 | 00000010 | 00010100 |
信息客户端的反序列话步骤如下：
反序列化出user_id
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000110 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 00000000 | 00000110 | 00000000 | 00001111 |
| 0x12 | 01000010 | 01000010 | 00000010 | 00010100 |
将黑体字部分的4个字节反序列化为user_id，为1000000（16进制为0x000F4240）
反序列化出好友列表的元素个数list_cnt:
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000110 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 00000000 | 00000110 | 00000000 | 00001111 |
| 0x12 | 01000010 | 01000010 | 00000010 | 00010100 |
将黑体字部分的2个字节反序列化为list_cnt，为2（16进制为0x0002）。
反序列化出好友列表中的每个好友信息
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000110 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 00000000 | 00000110 | 00000000 | 00001111 |
| 0x12 | 01000010 | 01000010 | 00000010 | 00010100 |
将第二排连续黑体的内容当成第一个好友的信息数据，其中前两个2个字节表示好友信息序列化后的长度（不含表示长度的这2个字节），反序列化好友信息序列化长度为6字节（16进制为0x0006），并记录第一个好友信息序列化开始的地址为0x8，将0x8起始的六个字节反序列化为friend_id为1000001(16进制为0x000F4241)， gender反序列化为1，年龄反序列化为18。之后通过记录的第一个好友信息序列化开始地址0x8加上好友信息序列化长度6减1，算出下一个好友的信息数据的起始地址为0xe，然后按照同样的反序列话好友的方法反序列化出第二个好友信息。
在需求变更后，好友信息结构体增加好友身高height字段后，服务器给用户1000000的回复的好友列表的序列化后的二进制数据具体如下：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000111 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 10101111 | 00000000 | 00000111 | 00000000 |
| 0x12 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 | 10100101 |
老版本收到数据后，按照步骤反序列化，在如下着色块开始第一个好友信息的反序列化：
| 0x0 | 00000000 | 00001111 | 01000010 | 01000000 | 00000000 | 00000010 |
| 0x6 | 00000000 | 00000111 | 00000000 | 00001111 | 01000010 | 01000001 |
| 0xc | 00000001 | 00010010 | 10101111 | 00000000 | 00000111 | 00000000 |
| 0x12 | 00001111 | 01000010 | 01000010 | 00000010 | 00010100 | 10100101 |
从0x6和ox7反序列化出第一个好友的序列化长度为7，好友信息的序列化开始地址为0x8，在反序列化完第一个好友的信息后（老版本看不到好友的身高信息，所以第一个好友信息的身高的序列信息老版本客户端未使用），使用记录的好友序列化信息的开始地址0x8加上好友序列化长度7减1，得到下个一个好友信息的内存开始地址为0xf；同样得到了正确的第二个好友信息的开始地址，然后反序列化出第二个好友的序列化长度为7，好友信息的序列化开始地址为0x11，能正确反序列化出好友的老版本下能看到的好友信息，从而避免的服务器的新老版本兼容，实现的列表结构体增量变化后向前兼容。
Claims (4)
1.一种向前兼容元素增量变化的数据传输方法，将数据转化为二进制序列化结构体列表进行传输，结构体列表在序列化时按照结构体中的定义字段进行平铺序列化，其特征在于：在序列化结构体列表时，在每个元素结构体的前面序列化该元素结构体的长度，在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址；
当新版本的定义字段相较于旧版本的定义字段存在增量时，按照最新版本定义的字段进行序列化结构体列表，每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本反序列化后使用元素的所有信息，旧版本反序列化之后不使用增量信息只使用旧版本定义的字段信息；
结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段定位每个元素起止地址，进行反序列化获取元素信息，若采用旧版本反序列化则不使用新增的元素信息。
2.根据权利要求1所述向前兼容元素增量变化的数据传输方法，其特征在于：结构体列表的前四个字节代表用户ID，第五和第六字节代表元素数量，第七和第八字节代表第一个元素的长度，之后是是第一个元素的信息，依次类推排布剩余元素的长度和元素信息。
3.一种向前兼容元素增量变化的数据传输***，包括服务器和客户端，所述服务器和所述客户端请求和回复的包通过二进制序列化方式来进行传输，其特征在于：服务器在序列化结构体列表的每个元素时在前面序列该结构体元素序列化后的长度，客户端在进行反序列化时，以前一个元素序列化开始的地址加上其序列化后的长度来定位后一个元素的序列化开始地址；
当服务器更新为新版本而客户端未及时更新时，服务器按照最新版本定义的字段进行序列化结构体列表，每个元素中新版本相较于旧版本的增量字段排在原有字段后面，新版本客户端反序列化后使用元素的所有信息，旧版本客户端反序列化之后不使用增量信息只使用旧版本定义的字段信息；
本***用于网络社交服务，结构体列表由用户ID字段、元素数量字段、每个元素的长度字段和每个元素的信息字段组成，当出现版本更新增加新的元素信息时，每个元素中增加的新字段排布在原有字段之后；根据每个元素的长度字段反序列化各个元素的信息，若采用旧版本客户端反序列化则不使用新增的元素信息。
4.根据权利要求3所述向前兼容元素增量变化的数据传输***，其特征在于：所述元素信息包含用户的网络好友信息特征。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011417771.2A CN112565267B (zh) | 2020-12-07 | 2020-12-07 | 向前兼容元素增量变化的数据传输方法及*** |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011417771.2A CN112565267B (zh) | 2020-12-07 | 2020-12-07 | 向前兼容元素增量变化的数据传输方法及*** |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112565267A CN112565267A (zh) | 2021-03-26 |
| CN112565267B true CN112565267B (zh) | 2023-05-02 |
Family
ID=75059095
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011417771.2A Active CN112565267B (zh) | 2020-12-07 | 2020-12-07 | 向前兼容元素增量变化的数据传输方法及*** |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112565267B (zh) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114818656B (zh) * | 2022-06-30 | 2022-09-23 | 深圳华锐分布式技术股份有限公司 | 基于灰度升级的二进制文件解析方法、装置、设备及介质 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8578134B1 (en) * | 2005-04-04 | 2013-11-05 | Globalfoundries Inc. | System and method for aligning change-of-flow instructions in an instruction buffer |
| CN108009172A (zh) * | 2016-10-27 | 2018-05-08 | 腾讯科技（深圳）有限公司 | 一种文件立体显示方法、装置及终端 |
| CN109194720A (zh) * | 2018-08-15 | 2019-01-11 | 京信通信***（中国）有限公司 | 主备机数据同步方法、装置和计算机设备 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101192148B (zh) * | 2006-12-01 | 2012-02-01 | 深圳迈瑞生物医疗电子股份有限公司 | 兼容新旧应用程序的数据处理方法及其数据存储方法 |
| CN102724308A (zh) * | 2012-06-13 | 2012-10-10 | 腾讯科技（深圳）有限公司 | 软件更新方法及软件更新*** |
| US10621156B1 (en) * | 2015-12-18 | 2020-04-14 | Amazon Technologies, Inc. | Application schemas for journal-based databases |
| CN106713423B (zh) * | 2016-12-06 | 2019-11-29 | 上海斐讯数据通信技术有限公司 | 一种云接入点控制器中分布式数据的处理方法及装置 |
| CN111124551B (zh) * | 2019-11-22 | 2023-11-17 | 矩阵元技术（深圳）有限公司 | 数据序列化、数据反序列化方法、装置和计算机设备 |
| CN111695076A (zh) * | 2020-06-15 | 2020-09-22 | 荆门汇易佳信息科技有限公司 | 基于超文本5的跨浏览器网页兼容标准构建方法 |
| CN111858103B (zh) * | 2020-07-30 | 2022-08-16 | 南京甄视智能科技有限公司 | 软件***内模块高低版本通信兼容实现方法 |
-
2020
- 2020-12-07 CN CN202011417771.2A patent/CN112565267B/zh active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8578134B1 (en) * | 2005-04-04 | 2013-11-05 | Globalfoundries Inc. | System and method for aligning change-of-flow instructions in an instruction buffer |
| CN108009172A (zh) * | 2016-10-27 | 2018-05-08 | 腾讯科技（深圳）有限公司 | 一种文件立体显示方法、装置及终端 |
| CN109194720A (zh) * | 2018-08-15 | 2019-01-11 | 京信通信***（中国）有限公司 | 主备机数据同步方法、装置和计算机设备 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112565267A (zh) | 2021-03-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110022289B (zh) | 数据传输方法、装置及*** | |
| CN112565267B (zh) | 向前兼容元素增量变化的数据传输方法及*** | |
| US20100115041A1 (en) | Creating a message readable by a plurality of heterogeneous recipients | |
| CN109189704B (zh) | 一种通用总线接口适配方法及装置 | |
| US7404186B2 (en) | Signature serialization | |
| CN103532828A (zh) | 一种基于扩展的xmpp协议的富文本格式实现***和方法 | |
| CN116703518A (zh) | 虚拟物品包发送方法、装置、设备和存储介质 | |
| CN107154931A (zh) | 一种客户端版本兼容的方法及装置 | |
| CN108880760B (zh) | 一种基于北斗卫星的大数据量可靠通信方法 | |
| CN107872441B (zh) | 生成设备属性配置文件的方法和装置 | |
| US20180191461A1 (en) | Interface Data Transmission Method, Data Transmission Interface, and Interface System | |
| CN111144578B (zh) | 一种分布式环境下的人工智能模型管理***及管理方法 | |
| WO2024001572A1 (zh) | 控制器功能更新方法、***、车辆和服务器 | |
| CN110839079B (zh) | 工作流***中的bi节点执行方法、装置、设备及介质 | |
| CN109684450B (zh) | 一种基于语义化标识的工业网络数据分发服务***及方法 | |
| CN106878145A (zh) | 一种自定义图片的显示方法、显示装置及显示*** | |
| CN115630614B (zh) | 数据传输方法、装置、电子设备与介质 | |
| CN103391333A (zh) | 支持guid迁移的网络及相关消息处理方法 | |
| CN110769049B (zh) | 一种配电终端及其soe数据上送方法 | |
| CN105636121A (zh) | 一种客户端登录服务器同步数据的方法及*** | |
| CN106982165A (zh) | 数据压缩方法及其*** | |
| CN114124200A (zh) | 一种分布式处理的天通多业务综合接入平台 | |
| CN101014023B (zh) | 一种会话标识匹配方法及装置以及通讯*** | |
| CN108920478B (zh) | 基于小***的批量数据分段采集方法 | |
| CN113452712A (zh) | 一种基于银联iso 8583报文的解析方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |