CN104780203A - 一种基于弹性云的多点接入方法 - Google Patents
一种基于弹性云的多点接入方法 Download PDFInfo
- Publication number
- CN104780203A CN104780203A CN201510128857.6A CN201510128857A CN104780203A CN 104780203 A CN104780203 A CN 104780203A CN 201510128857 A CN201510128857 A CN 201510128857A CN 104780203 A CN104780203 A CN 104780203A
- Authority
- CN
- China
- Prior art keywords
- server
- communication
- client
- data
- service
- 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.)
- Pending
Links
Landscapes
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种基于弹性云的多点接入方法,能连接多个局域网实现弹性云内部各节点之间的数据交互。本发明包括以下特征:采用通用的标准通讯协议和接口规范:为满足不同业务***的数据交互,通讯层必须和应用无关,采用通用的标准通讯协议和接口规范,这样就可以保证不同的应用在通用的通讯底层上进行协同。提供统一的通讯模块供调用:为统一业务***服务器端,客户端之间的通讯,底层通讯模块对通讯的实现与一些通讯协议进行了封装,服务端程序,客户端程序均统一调用底层通讯模块,采用TCP长连接方式进行连接和通讯。应用程序的开发可无需考虑通讯部分的实现,专注本身功能的实现。
Description
技术领域
本发明涉及一种基于弹性云的多点接入方法。
背景技术
随着信息时代不断前进的脚步,企业信息化建设也不断深入,业务***数量不断增加,各业务***之间数据交互,各子业务***与核心业务***之间数据交互,诸如此类场景的应用需求不断出现。而随着企业的发展壮大,对这些***通讯的要求也越来越高,原来只在自己内部局域网应用的***可能就要扩展到互联网来使用,比如原来一套人事管理***就只在公司内部使用,随着各地分公司的建立,各分公司也需要使用这套***并且总公司也需要所有的数据集中到一起统一管理,那么这套***就必须部署到互联网才能让各地分公司都能访问,而基于网络安全性考虑,内部私有的***部署到互联网是不合适的,同时因为网络安全的考虑,不少企业,政府机关等都做了内外网的隔离,以有限的方式提供内外网的访问,也不适宜这种内网直接访问外网的方案,这就需要一种可靠安全的方法能让处于不同网络的业务***能进行数据交互,也就是能通过互联网来连接各个局域网,构建一个“私有网络”,在这个“私有网络”范围内,不能进行对该网络外的数据交互,但是却能不受内外网的限制,在各个节点之间进行数据交互,只要接入这个“私有网络”,就能访问到该网络内部任意一个节点,这样既保证安全性,又能不受内外网限制来进行数据交互。
目前基于网络通讯的众多技术与产品,虽然很多都实现了内外网穿透与点对点数据交互,但基本只是单一应用,并没有能构成这样一个“私有网络”能够使接入网络的节点与其他节点能进行数据交互,并且接入的节点也能提供接入口,构成能多点接入的弹性云。
发明内容
本发明要解决技术问题是:克服现有技术的上述不足,利用纯软件技术手段,提供一种基于弹性云的多点接入方法,能连接多个局域网实现弹性云内部各节点之间的数据交互。
为了解决以上技术问题,本发明提供的一种基于弹性云的多点接入方法,包括以下特征:
采用通用的标准通讯协议和接口规范:为满足不同业务***的数据交互,通讯层必须和应用无关,采用通用的标准通讯协议和接口规范,这样就可以保证不同的应用在通用的通讯底层上进行协同。
提供统一的通讯模块供调用:为统一业务***服务器端,客户端之间的通讯,底层通讯模块对通讯的实现与一些通讯协议进行了封装,服务端程序,客户端程序均统一调用底层通讯模块,采用TCP长连接方式进行连接和通讯。应用程序的开发可无需考虑通讯部分的实现,专注本身功能的实现。
本发明的部署架构包含以下几个组成部分:
客户端:各业务***的客户端,必须接入弹性云才能连接到具体的业务***服务器。
通讯服务器:负责数据的路由与中转,保证数据能中转到达目标机器,不需要数据库,可方便的部署与接入弹性云,在接入的同时也提供接口可接受其他通讯服务器与客户端的接入。
应用服务器:业务服务器,处理特定的业务,部署企业的业务***,提供各种具体的应用服务。
索引服务器:连接管理,负责分配用户的索引服务器,使客户端知道自己的业务数据与哪个应用服务器进行交互。索引服务器实际上是应用服务器,提供网络中应用服务器的应用与寻址服务。应用服务器接入网络应向索引服务器提供注册信息,即自己的ID和提供的是什么服务。例如应用服务器1提供的是网上开票服务,应用服务器2提供的是税企互动服务,客户端连接通讯服务器后应向索引服务器查询具体的应用服务器ID,如税企互动客户端就能查询到需要与应用服务器2进行数据交互。索引服务器应设为一个固定的ID,如127.0.0.1(ID,与实际IP地址无关),这样客户端可以连接任意一台通讯服务器,向127.0.0.1的ID发送查询请求,获知具体应用的服务器ID后就可与具体的应用服务器进行数据交互。实现任意地点登录都可访问相应应用。
因服务端程序均统一调用底层通讯模块,所有服务器均具有通讯服务器的功能。
服务端必须有一个唯一的ID进行标识,该ID以IP地址形式提供,一般与本机IP一致,但也可以任意指定。服务端之间的数据转发依赖此ID进行。底层通讯模块传输的通讯数据包的包头中包含发送方客户端ID,发送方服务器ID,接收方服务器ID,接收方客户端ID,根据始发服务器ID与终点服务器ID,中间的数据转发由通讯服务器完成。
为保证安全性,服务器之间的连接必须有授权认证,通过配置文件进行设置。例如服务器A连接服务器B,A的配置文件中必须有登录服务器B的ID和密码,B的配置文件中也需要有A的ID和认证密码,两者匹配才能建立连接。
服务端之间的连接由配置文件指定,底层通讯模块自动根据配置文件中指定的服务器地址连接其他服务端并交换各自的路由信息,形成网络中任意服务器/客户端的数据交互可达。
服务器端之间的连接可以配置为以下3种方式:
1、 主动连接:服务程序启动后主动连接其他服务器,这是最常见的方式。
2、 接受连接:服务程序启动后并不主动连接其他服务器,而是等待其他服务器的连接,适用于位于互联网的服务器。由于内外网的隔离,不能连接内网的服务器,只能等待内网的服务器连接。
3、 双向连接:服务程序启动后主动连接其他服务器,同时等待该服务器的连接,即服务器之间会有两条SOCKET连接,适用于网络通讯情况恶劣的环境,当其中一条连接断开的时候,底层通讯模块会自动使用另一条连接传输数据。由于网络情况不稳定,可能存在连接经常断开的情况,底层通讯模块有断连检测及自动重连机制,当一条连接断开重连的时候,可以使用另一条连接进行数据传输。
服务端之间的数据转发寻址机制:
数据的寻址转发依赖传输数据包头中的服务器ID与客户端ID。底层通讯模块会自动在传输的数据包加上该数据包头。数据包头有4个字段,指定了目标服务器ID,目标客户端ID,发送者服务器ID,发送者(客户端)ID。客户端调用底层通讯模块发送数据的时候可分别指定服务器ID和客户端ID,也可指定其中任意一个或两者均不指定,可分为以下几种情况:
1、 指定服务器ID和客户端ID:通讯服务器将数据转发到指定服务器,该服务器再将数据转发到指定客户端。指定的客户端必须已连接到指定服务器,否则数据转发失败。
2、 指定客户端ID:通讯服务器将数据直接转发到指定客户端,该客户端必须已连接通讯服务器。这种情况是同一服务端的客户端之间的数据交互。
3、 指定服务器ID:该服务器ID一般是应用服务器的ID,通讯服务器将数据转发到指定的服务器。
4、 不指定任何服务器ID和客户端ID:通讯服务器将数据转发到默认配置的应用服务器。
数据转发的寻址由底层通讯模块完成,不依赖数据库,在程序启动时根据配置文件接入弹性云时构造路由表来完成。该路由表由3个字段组成:
目标服务器ID,转发服务器ID,转发次数。
该路由表中目标服务器ID记录所有本服务器能转发到的目标服务器的ID列表。转发服务器ID则必须是当前与自己连接的其他服务器的ID。转发次数是指通过几次转发才能到达目标服务器。
考虑以下一个场景:李四对王五说:“我认识张三,你要找张三就找我。”,王五对赵六说:“我能找到张三,你找张三的话找我。”,赵六说:“我有封信要给张三,你帮我带给他。”,于是王五把信交给李四,李四再把信交给张三。这就是地下工作者的单线联系。数据转发的寻址类似于此,每台服务器都不知道完整的数据转发路径,但是知道正确的转发方向。当一台通讯服务器接入这个网络的时候,会与自己相连接的服务器之间进行路由表信息的交换。当发现路由表有变动的时候,会把变动的信息通知给所有与自己相连的服务器,这样层层通知,整个网络的路由表就得到了更新。
路由表的构建:
当一台通讯服务器接入网络,与其他服务器通过认证建立连接后,底层通讯模块就会进行路由表信息的交换。会把自己的路由表信息通知给连接的通讯服务器,消息格式与路由表格式略有区别,如下表:
转发服务器ID | 目标服务器数量 | 服务器ID | 服务器ID | . . . |
这个路由表信息的意思是:“我能通过转发到达以下服务器。”,所以信息中只需要有一条转发服务器ID记录,即本机服务器ID,然后是可到达的目标服务器数量,接着就是目标服务器的ID列表。收到消息的通讯服务器解析信息后就完成了自己的路由表更新,然后会把更新的信息通知给所有与自己相连接的服务器,每一个收到信息的服务器都会在更新自己的路由表后把信息再转发给所有与自己连接的服务器,这样层层通知,网络中所有服务器的路由表都得到了正确的更新。
附图说明
下面结合附图对本发明作进一步的说明。
图1是弹性云的网络部署架构示例。
图2是图1中各服务器的路由表信息。
具体实施方式
下面根据附图详细说明本发明,对本发明实施例中的技术方案进行清楚、完整地描述,数据转发寻址的详细实现与各服务器的路由表如何构建。附图示例只是为方便说明本发明的技术方案而构造,实际应用不一定与示例相同。
图1中每一个服务器都有一个唯一的ID标识,该ID以IP形式提供,如0.0.0.1,但是与实际的IP地址无关。ID可以任意指定,但需要保证在服务器构成的弹性云中是唯一的。客户端同样也有唯一的ID标识,由客户端程序自行约定。弹性云中服务器,客户端之间数据交互是通过ID来寻址路由进行数据的转发,不依赖实际的IP地址(仅接入弹性云的物理机器需要知道接入点的IP地址以接入弹性云)。
假设图2中客户端B通过连接通讯服务器D接入了弹性云,需要请求某个业务***的数据,需要先到索引服务器查询该业务***所在的服务器ID,通讯服务器D将会查自己的路由表,目标服务器是索引服务器,将数据转发到通讯服务器E,通讯服务器E查自己的路由表,将数据转发到通讯服务器C,通讯服务器C将数据转发到通讯服务器B,通讯服务器B将数据转发到通讯服务器A,通讯服务器A最终将数据转发到索引服务器。索引服务器接收到数据,通过查询得到客户端请求的业务***在应用服务器3,完成处理后将结果数据发回客户端,是根据数据包头中的发送者服务器ID,发送者(客户端)ID来定位,同样查自己的路由表,通讯服务器D的数据是转发到通讯服务器A,再由A->B->C->E->D->客户端B,完成一次完整的数据交互。
客户端B获知自己的业务***在应用服务器3后,就不再需要与索引服务器产生数据交互,只需将具体业务请求数据发送给通讯服务器D,同理通过D->E->C->应用服务器3的路径到达应用服务器3,应用服务器3完成数据处理后通过C->E->D->客户端B的路径将结果数据发回客户端B,完成业务***的数据交互。
下面详细说明图2中各服务器的路由表构建过程:
假设图2中通讯服务器D接入弹性云,与通讯服务器E建立连接,E将会把自己的路由表信息通知给D,消息格式如下:
转发服务器ID | 目标服务器数量 | 服务器ID | 服务器ID | . . . |
因为E告诉D的信息是:“我能通过转发到达以下服务器。”,所以信息中只需要有一条转发服务器ID记录,即E的服务器ID,然后是可到达的目标服务器数量,接着就是目标服务器的ID列表。D解析信息后就构建完成了自己的路由表:应用服务器1,2,3,通讯服务器A,B,C,E,索引服务器的数据都是转发到E。
E接收到的D的路由表信息只有一条,就是D的数据转发到D,将其加入到自己的路由表更新后,会把更新的信息通知给所有与自己相连接的服务器(除了D,因为已进行路由表信息交换),信息类似下表:
通讯服务器E的ID(转发目标) | 通讯服务器D的ID (最终目标) | 1(转发次数) |
图2中通讯服务器C与E连接,C解析信息后知道到通讯服务器D的数据要转发到E,更新路由表后把更新信息发送给应用服务器3和通讯服务器B:
通讯服务器C的ID(转发目标) | 通讯服务器D的ID (最终目标) | 2(转发次数) |
每一个收到信息的服务器都会在更新自己的路由表后把信息中第一个字段(转发服务器ID)替换为自己的ID,然后再转发给所有与自己连接的服务器,这样层层通知,网络中所有服务器的路由表都得到了正确的更新。
路由表的回环处理:
图2中的服务器都是线性连接,没有构成回环,如果图中通讯服务器D再与通讯服务器A连接,通讯服务器A,B,C,D,E就构成了一个回环,这时通讯服务器A将会收到两条到服务器D的路由信息,一条是D发来的,D->D,一条是B发来的,D->B,一条转发路径是直接转发到D,另一条路径是B->C->E->D,最优转发路径显然是D->D。构成回环,路由表中的每一条信息都将会得到更新,D连接E后更新完自己的路由表,再连接A,通知A的不仅是D的信息,还有“所有服务器都通过D转发”的路由信息,A将会收到E->D的路由信息,与自己现有的路由表信息E->B如何判断哪条线路最优,由于服务器不知道完整的转发路径,只能依靠路由表信息中的转发次数字段了。
再看上面说明中D连接到E的例子,E接收到D->D的信息,转发次数为1,然后将转发次数+1,D->E的信息通知给C,C同样将转发次数+1,D->C的信息通知给应用服务器3和通讯服务器B,最后A的路由表信息将会是下表所列:
目标服务器 | 转发服务器 | 转发次数 |
应用服务器1 | 应用服务器1 | 1 |
应用服务器2 | 通讯服务器B | 2 |
应用服务器3 | 通讯服务器B | 3 |
通讯服务器B | 通讯服务器B | 1 |
通讯服务器C | 通讯服务器B | 2 |
通讯服务器D | 通讯服务器B | 4 |
通讯服务器E | 通讯服务器B | 3 |
索引服务器 | 索引服务器 | 1 |
当D再连接A时,A收到并解析出的路由信息将会是下表:
目标服务器 | 转发服务器 | 转发次数 |
应用服务器1 | 通讯服务器D | 6 |
应用服务器2 | 通讯服务器D | 5 |
应用服务器3 | 通讯服务器D | 4 |
通讯服务器B | 通讯服务器D | 4 |
通讯服务器C | 通讯服务器D | 3 |
通讯服务器D | 通讯服务器D | 1 |
通讯服务器E | 通讯服务器D | 2 |
索引服务器 | 通讯服务器D | 6 |
D提供的路由表中,只有D和E的转发次数比自己的路由表中的转发次数少,因此A将会把路由表中的这两条信息更新为D提供的信息,再将这两条信息的转发次数+1,转发服务器ID改为自己的ID通知给与自己相连的应用服务器1,通讯服务器B和索引服务器,其他服务器也照此动作,这样所有服务器的路由表都更新为了最短转发路径。A在更新自己的最短路径路由的时候,原来的路由信息并不删除,而是作为备用信息,以链表形式添加在最短路由的尾部,这样当D与A之间的连接断开,A删除D->D的路由,可以将D->B的原路由信息顶替上来,A与D之间仍然可以进行信息交互。
以上只是路由表信息基本的解析处理过程,加上服务器断连删除路由表的操作,实际上程序处理起来要复杂的多,更新路由表也不仅仅更新最短路径,需要将长路径也作为备用路径记录下来,再通知其他服务器,还要防止路由信息无限回环传递等细节问题需要处理。
数据群发的处理:
当需要群发数据的时候,例如类似业务***发送给所有客户端的通知消息,类似QQ的群聊天信息,由于可能需要经过数据转发,将数据复制n份发送,那么中转过程将会极大浪费带宽,因此***设计成中转数据仅一条,到目标服务器后再分发至客户端,对此需要做特殊处理。首先,作为信息发送方,应用服务器需要将接收信息的客户端按所在服务器分类,所有接收信息的用户分属(连接)n个服务器,需要将其分成n个组,然后将每组用户所在服务器ID,用户ID列表,信息内容,大小作为参数调用底层通讯模块进行消息发送,共发送n条数据。
然后底层通讯模块将目标服务器,用户列表等信息及数据进行组包,将数据发送到目标服务器。
最后目标服务器收到信息,解析出用户列表,将数据分发到客户端。
例如客户端1,2,3连接到通讯服务器A,客户端4,5,6连接到通讯服务器D,应用服务器1将会生成两个数据包分别分送到通讯服务器A和D,发送到A的数据包带客户端1,2,3的ID列表, 发送到B的数据包带客户端4,5,6的ID列表,通讯服务器A和D收到包后分别将数据分发到连接自己的客户端。这样数据在服务器之间中转时数据量最小,也提高了传输效率。
除上述实施例外,本发明还可以有其他实施方式。凡采用等同替换或等效变换形成的技术方案,均落在本发明要求的保护范围。
Claims (5)
1. 一种基于弹性云的多点接入方法,其特征在于:
采用通用的标准通讯协议和接口规范:为满足不同业务***的数据交互,通讯层必须和应用无关,采用通用的标准通讯协议和接口规范,保证不同的应用在通用的通讯底层上进行协同;
提供统一的通讯模块供调用:为统一业务***服务器端,客户端之间的通讯,底层通讯模块对通讯的实现与一些通讯协议进行了封装,服务端程序,客户端程序均统一调用底层通讯模块,采用TCP长连接方式进行连接和通讯;
部署架构包含以下几个组成部分:
客户端:各业务***的客户端,接入弹性云才能连接到具体的业务***服务器;
通讯服务器:负责数据的路由与中转,保证数据能中转到达目标机器,不需要数据库,可方便的部署与接入弹性云,在接入的同时也提供接口可接受其他通讯服务器与客户端的接入;
应用服务器:业务服务器,处理特定的业务,部署企业的业务***,提供各种具体的应用服务;
索引服务器:连接管理,负责分配用户的索引服务器,使客户端知道自己的业务数据与哪个应用服务器进行交互,提供网络中应用服务器的应用与寻址服务,应用服务器接入网络应向索引服务器提供注册信息,即自己的ID和提供的是什么服务;
服务端有一个唯一的ID进行标识,该ID以IP地址形式提供,服务端之间的数据转发依赖此ID进行;底层通讯模块传输的通讯数据包的包头中包含发送方客户端ID,发送方服务器ID,接收方服务器ID,接收方客户端ID,根据始发服务器ID与终点服务器ID,中间的数据转发由通讯服务器完成;
服务端之间的连接由配置文件指定,底层通讯模块自动根据配置文件中指定的服务器地址连接其他服务端并交换各自的路由信息,形成网络中任意服务器/客户端的数据交互可达。
2. 根据权利要求1所述的基于弹性云的多点接入方法,其特征在于:所述服务器端之间的连接可以配置为以下3种方式:
1、 主动连接:服务程序启动后主动连接其他服务器,这是最常见的方式;
2、 接受连接:服务程序启动后并不主动连接其他服务器,而是等待其他服务器的连接,适用于位于互联网的服务器,由于内外网的隔离,不能连接内网的服务器,只能等待内网的服务器连接;
3、 双向连接:服务程序启动后主动连接其他服务器,同时等待该服务器的连接,即服务器之间会有两条SOCKET连接,适用于网络通讯情况恶劣的环境,当其中一条连接断开的时候,底层通讯模块会自动使用另一条连接传输数据;由于网络情况不稳定,可能存在连接经常断开的情况,底层通讯模块有断连检测及自动重连机制,当一条连接断开重连的时候,可以使用另一条连接进行数据传输。
3. 根据权利要求2所述的基于弹性云的多点接入方法,其特征在于:所述服务端之间的数据转发寻址机制如下:
数据的寻址转发依赖传输数据包头中的服务器ID与客户端ID,底层通讯模块会自动在传输的数据包加上该数据包头,数据包头有4个字段,指定了目标服务器ID,目标客户端ID,发送者服务器ID,发送者(客户端)ID。
4. 根据权利要求1所述的基于弹性云的多点接入方法,其特征在于:所述客户端调用底层通讯模块发送数据时,分为以下几种情况:
1、指定服务器ID和客户端ID:通讯服务器将数据转发到指定服务器,该服务器再将数据转发到指定客户端,指定的客户端必须已连接到指定服务器,否则数据转发失败;
2、指定客户端ID:通讯服务器将数据直接转发到指定客户端,该客户端必须已连接通讯服务器,这种情况是同一服务端的客户端之间的数据交互;
3、指定服务器ID:该服务器ID一般是应用服务器的ID,通讯服务器将数据转发到指定的服务器;
4、不指定任何服务器ID和客户端ID:通讯服务器将数据转发到默认配置的应用服务器。
5. 根据权利要求4所述的基于弹性云的多点接入方法,其特征在于:数据转发的寻址由底层通讯模块完成,不依赖数据库,在程序启动时根据配置文件接入弹性云时构造路由表来完成,该路由表由3个字段组成:
目标服务器ID,转发服务器ID,转发次数;
该路由表中目标服务器ID记录所有本服务器能转发到的目标服务器的ID列表;转发服务器ID则必须是当前与自己连接的其他服务器的ID;转发次数是指通过几次转发才能到达目标服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510128857.6A CN104780203A (zh) | 2015-03-23 | 2015-03-23 | 一种基于弹性云的多点接入方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201510128857.6A CN104780203A (zh) | 2015-03-23 | 2015-03-23 | 一种基于弹性云的多点接入方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104780203A true CN104780203A (zh) | 2015-07-15 |
Family
ID=53621437
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201510128857.6A Pending CN104780203A (zh) | 2015-03-23 | 2015-03-23 | 一种基于弹性云的多点接入方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104780203A (zh) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105978974A (zh) * | 2016-05-13 | 2016-09-28 | 捷开通讯科技(上海)有限公司 | 电子装置的连接***与方法 |
CN107360205A (zh) * | 2016-05-09 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 数据报文的传输方法及装置、*** |
CN114301915A (zh) * | 2021-12-28 | 2022-04-08 | 武汉杰创达科技有限公司 | 一种云商平台商品信息处理方法 |
-
2015
- 2015-03-23 CN CN201510128857.6A patent/CN104780203A/zh active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107360205A (zh) * | 2016-05-09 | 2017-11-17 | 阿里巴巴集团控股有限公司 | 数据报文的传输方法及装置、*** |
CN107360205B (zh) * | 2016-05-09 | 2020-12-29 | 阿里巴巴集团控股有限公司 | 数据报文的传输方法及装置、*** |
CN105978974A (zh) * | 2016-05-13 | 2016-09-28 | 捷开通讯科技(上海)有限公司 | 电子装置的连接***与方法 |
CN114301915A (zh) * | 2021-12-28 | 2022-04-08 | 武汉杰创达科技有限公司 | 一种云商平台商品信息处理方法 |
CN114301915B (zh) * | 2021-12-28 | 2024-02-20 | 武汉杰创达科技有限公司 | 一种云商平台商品信息处理方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102594711B (zh) | 一种在边缘设备上的报文转发方法和边缘设备 | |
US20200059976A1 (en) | IoT DEVICE CONNECTIVITY, DISCOVERY, AND NETWORKING | |
EP2583415B1 (en) | Method, diameter node, and computer readable medium for providing dynamic origination-based routing key registration in a diameter network | |
CN105634956B (zh) | 一种报文转发方法、装置和*** | |
JP4479647B2 (ja) | 経路生成システム、経路生成方法、経路管理サーバ、中継装置、端末装置および制御プログラム | |
CN110601906B (zh) | 一种基于区块链的数据传输方法及装置 | |
CN103036784A (zh) | 用于自组织二层企业网络架构的方法和装置 | |
CN103475750A (zh) | 一种适用于多出口网络的地址转换方法及设备 | |
CN104980427A (zh) | 用于内容中心网络中的简单的服务发现的***和方法 | |
CN102055816A (zh) | 一种通信方法、业务服务器、中间设备、终端及通信*** | |
CN103209108A (zh) | 一种基于dvpn的路由生成方法和设备 | |
CN102739497A (zh) | 一种路由自动生成方法及其装置 | |
CN102739541A (zh) | 一种路由功能启动及数据传输的方法、设备和*** | |
WO2015108106A1 (ja) | パケット転送装置、制御装置、通信システム、通信方法及びプログラム | |
CN104094243A (zh) | 信息处理装置、信息处理方法和程序 | |
CN104980484A (zh) | 用于内容中心网络中的装置注册和发现的***和方法 | |
CN103561122B (zh) | IPv6地址配置方法、IPv6客户端及服务器 | |
CN109257392A (zh) | 一种命令处理方法、装置、服务器和存储介质 | |
CN104780203A (zh) | 一种基于弹性云的多点接入方法 | |
CN109586958A (zh) | 双***装置的配置管理方法及双***装置 | |
CN108966363A (zh) | 一种连接建立方法及装置 | |
WO2022160864A1 (zh) | 用于智能设备入网的方法、装置及智能设备 | |
CN101766007A (zh) | 用于提供racf配置信息的方法和*** | |
CN108234165A (zh) | 一种配置网关的方法和装置 | |
CN101572729B (zh) | 一种虚拟专用网节点信息的处理方法及相关设备、*** |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20150715 |
|
WD01 | Invention patent application deemed withdrawn after publication |