U.S. patent application number 15/133713 was filed with the patent office on 2016-08-11 for system and method of message routing using name-based identifier in a distributed computing environment.
The applicant listed for this patent is PTC Inc.. Invention is credited to Rick Bullotta, Bob DeRemer, Mike Mahoney.
Application Number | 20160234157 15/133713 |
Document ID | / |
Family ID | 54143227 |
Filed Date | 2016-08-11 |
United States Patent
Application |
20160234157 |
Kind Code |
A1 |
Mahoney; Mike ; et
al. |
August 11, 2016 |
SYSTEM AND METHOD OF MESSAGE ROUTING USING NAME-BASED IDENTIFIER IN
A DISTRIBUTED COMPUTING ENVIRONMENT
Abstract
A system and method of routing messages in a distributed
computing environment is provided. The method includes providing a
platform server, a set of intermediary servers, and a set of edge
servers, collectively defining a network. The method includes
binding, at the platform server, at a first instance, the end-point
device to the platform server wherein the platform server binds, at
the first instance, the end-point device using a non-addressable
name value associated to the end-point device. The binding
associates a first path across the network. The method includes
communicating a first message to the end-point device along the
first path. Method includes rebinding, at the platform server, at a
second instance, the end-point device to the platform server, where
the rebinding uses the non-addressable name value and associates a
second path across the network. The method includes communicating a
second message to the end-point device along the second path.
Inventors: |
Mahoney; Mike; (Needham,
MA) ; DeRemer; Bob; (Needham, MA) ; Bullotta;
Rick; (Phoenixville, PA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
PTC Inc. |
Needham |
MA |
US |
|
|
Family ID: |
54143227 |
Appl. No.: |
15/133713 |
Filed: |
April 20, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
14222123 |
Mar 21, 2014 |
9350812 |
|
|
15133713 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 67/02 20130101;
H04L 69/08 20130101; H04L 61/15 20130101; H04L 67/10 20130101; H04L
67/141 20130101; H04L 61/103 20130101; H04L 61/3065 20130101 |
International
Class: |
H04L 29/12 20060101
H04L029/12; H04L 29/08 20060101 H04L029/08 |
Claims
1. A computer-implemented method of communication between a
platform server and an end-point device, the method comprising:
providing a platform server, a set of intermediary servers, and a
set of edge servers, collectively defining a network, wherein an
end-point device communicates to an edge server of the set of edge
servers, wherein the set of edge servers communicates to the set of
intermediary servers, and wherein the set of intermediary servers
communicates to a platform server; binding, at the platform server,
at a first instance, the end-point device to the platform server,
wherein the platform server binds, at the first instance, the
end-point device using a non-addressable name value associated to
the end-point device, wherein the binding, at the first instance,
associates a first path across the network, and wherein the first
path is defined between the end-point device and the platform
server across one or more intermediary servers and one or more edge
servers, including a first intermediary server; communicating, at
the platform server, a first message to the end-point device along
the first path; rebinding, at the platform server, at a second
instance, the end-point device to the platform server, wherein the
platform server binds, at the second instance the end-point device,
using the non-addressable name value associated to the end-point
device, wherein the rebinding, at the second instance, associates a
second path across the network, wherein the second path is defined
between the end-point device and the platform server across one or
more intermediary servers and one or more edge servers, including a
second intermediary server; communicating, at the platform server,
a second message to the end-point device along the second path.
2. The computer-implemented method of claim 1 further comprising:
receiving, at the platform server, at a given instance between the
first and second instances, a request to unbind the end-point
device from the platform server, wherein the platform server
unbinds the end-point device based on the unbind request, wherein
the unbinding dissociates the first path defined between the
end-point device and the platform server.
3. The computer-implemented method of claim 1, wherein each of the
first path and the second path comprises a connection handle to an
established persistent connection.
4. The computer-implemented method of claim 3, wherein the
established persistent connection comprises a WebSocket
connection.
5. The computer-implemented method of claim 1, wherein the
non-addressable name value comprises a character string.
6. The computer-implemented method of claim 1 further comprising:
binding, at the platform server, at the first instance, a second
end-point device to the platform server, wherein the platform
server binds, at the first instance, the second end-point device
based on a second non-addressable name value associated to the
second end-point device.
7. The computer-implemented method of claim 6, wherein the binding
of the first end-point device and the binding of the second
end-point device is the result of a single bind request.
8. The computer-implemented method of claim 1, wherein at least one
of the first path and the second path includes at least two
intermediary servers.
9. A computer-implemented method of communication between a
platform server and an end-point device, the method comprising:
providing a platform server, a set of intermediary servers, and a
set of edge servers, collectively defining a network, wherein an
end-point device communicates to an edge server of the set of edge
servers, wherein the set of edge servers communicates to the set of
intermediary servers, and wherein the set of intermediary servers
communicates to the platform server; binding, at an intermediary
server of the set of intermediary servers, at a first instance, the
end-point device to the intermediary server, wherein the
intermediary server binding at the first instance the end-point
device based on a non-addressable name value associated to the
end-point device, wherein the binding, at the first instance,
associates a given persistent connection to a given edge server of
the set of edge servers, the given edge server communicating with
the end-point device; receiving, at the intermediary server, a
signal from platform server, the signal having a value associated
with the non-addressable name value of the end-point device;
determining at the intermediary server, a persistent connection
among a set of persistent connection having been established to the
set of edge servers, wherein the non-addressable name value has
been associated to the persistent connection during the binding;
and transmitting, at the intermediary server, the signal to the
end-point device using the determined persistent connection.
10. A non-transitory computer readable medium having instruction
stored thereon, wherein the instructions, when executed by a
processor, cause the processor to: provide a platform server, a set
of intermediary servers, and a set of edge servers, collectively
defining a network, wherein an end-point device communicates to an
edge server of the set of edge servers, the set of edge servers
communicates to the set of intermediary servers, and the set of
intermediary servers communicates to a platform server; bind, at a
platform server, at a first instance, the end-point device to the
platform server, wherein the platform server binds, at the first
instance, the end-point device based on a non-addressable name
value associated to the end-point device, wherein the binding, at
the first instance, associates a first path across the network,
wherein the first path is defined between the end-point device and
the platform server across one or more intermediary servers and one
or more edge servers, including a first intermediary server;
communicate, at the platform server, a first message to the
end-point device along the first path; rebind, at the platform
server, at a second instance, the end-point device to the platform
server, wherein the platform server binds, at the second instance,
the end-point device based on the non-addressable name value
associated to the end-point device, wherein the rebinding, at the
second instance, associates a second path across the network,
wherein the second path is defined between the end-point device and
the platform server across one or more intermediary servers and one
or more edge servers, including a second intermediary server;
communicate, at the platform server, a second message to the
end-point device along the second path.
11. The computer readable medium of claim 10, wherein the
instructions further comprise: receive, at the platform server, at
a given instance between the first and second instances, a request
to unbind the end-point device from the platform server, wherein
the platform server unbinds the end-point device based on the
unbind request, wherein the unbinding dissociates the first path
defined between the end-point device and the platform server.
12. The computer readable medium of claim 10, wherein each of the
first path and the second path comprises a connection handle to an
established persistent connection.
13. The computer readable medium of claim 12, wherein the
established persistent connection comprises a WebSocket
connection.
14. The computer readable medium of claim 10, wherein the
non-addressable name value comprises a character string.
15. The computer readable method of claim 10, wherein the
instructions further comprise: bind, at the platform server, at the
first instance, a second end-point device to the platform server,
wherein the platform server binds, at the first instance, the
second end-point device based on a second non-addressable name
value associated to the second end-point device.
16. The computer readable medium of claim 15, wherein the binding
of the first end-point device and the binding of the second
end-point device is the result of a single bind request.
17. The computer readable medium of claim 10, wherein at least one
of the first path and the second path includes at least two
intermediary servers.
18. A non-transitory computer readable medium having instruction
stored thereon, wherein the instructions, when executed by a
processor, cause the processor to: provide a platform server, a set
of intermediary servers, and a set of edge servers, collectively
defining a network, wherein an end-point device communicates to an
edge server of the set of edge servers, wherein the set of edge
servers communicates to the set of intermediary servers, and
wherein the set of intermediary servers communicates to the
platform server; bind, at an intermediary server of the set of
intermediary servers, at a first instance, the end-point device to
the intermediary server, wherein the intermediary server binds, at
the first instance, the end-point device based on a non-addressable
name value associated to the end-point device, wherein the binding,
at the first instance, associates a given persistent connection to
a given edge server of the set of edge servers, the given edge
server communicating with the end-point device; receive, at the
intermediary server, a signal from platform server, the signal
having a value associated with the non-addressable name value of
the end-point device; determine a persistent connection among a set
of persistent connection having been established to the set of edge
servers, wherein the non-addressable name value has been associated
to the persistent connection during the binding; and transmit, at
the intermediary server, the signal to the end-point device using
the determined persistent connection.
19. A system comprising: a processor; and a memory, the memory
storing instructions that, when executed by the processor, cause
the processor to: provide a platform server, a set of intermediary
servers, and a set of edge servers, collectively defining a
network, wherein an end-point device communicates to an edge server
of the set of edge servers, wherein the set of edge servers
communicates to the set of intermediary servers, and wherein the
set of intermediary servers communicates to a platform server;
bind, at a platform server, at a first instance, the end-point
device to the platform server, wherein the platform server binds,
at the first instance, the end-point device based on a
non-addressable name value associated to the end-point device,
wherein the binding, at the first instance, associates a first path
across the network, and wherein the first path is defined between
the end-point device and the platform server across one or more
intermediary servers and one or more edge servers, including a
first intermediary server; communicate, at the platform server, a
first message to the end-point device along the first path; rebind,
at the platform server, at a second instance, the end-point device
to the platform server, wherein the platform server binds, at the
second instance, the end-point device based on the non-addressable
name value associated to the end-point device, wherein the
rebinding, at the second instance, associates a second path across
the network, and wherein the second path is defined between the
end-point device and the platform server across one or more
intermediary servers and one or more edge servers, including a
second intermediary server; communicate, at the platform server, a
second message to the end-point device along the second path.
20. A system comprising: a processor; and a memory, the memory
storing instructions that, when executed by the processor, cause
the processor to: provide a platform server, a set of intermediary
servers, and a set of edge servers, collectively defining a
network, wherein an end-point device communicates to an edge server
of the set of edge servers, wherein the set of edge servers
communicates to the set of intermediary servers, and wherein the
set of intermediary servers communicates to the platform server;
bind, at an intermediary server of the set of intermediary servers,
at a first instance, the end-point device to the intermediary
server, wherein the intermediary server binds, at the first
instance, the end-point device based on a non-addressable name
value associated to the end-point device, and wherein the binding,
at the first instance, associates a given persistent connection to
a given edge server of the set of edge servers, the given edge
server communicating with the end-point device; receive, at the
intermediary server, a signal from platform server, the signal
having a value associated with the non-addressable name value of
the end-point device; determine a persistent connection among a set
of persistent connection having been established to the set of edge
servers, wherein the non-addressable name value has been associated
to the persistent connection during the binding; and transmit, at
the intermediary server, the signal to the end-point device using
the determined persistent connection.
Description
FIELD OF THE INVENTION
[0001] This invention generally relates to operations of a
distributing computing environment. More particularly, in certain
embodiments, the invention relates to message routing using a
name-based identifier in a distributed computing environment.
BACKGROUND
[0002] The business of building a connected world, also referred to
as the Internet of Things, is rapidly growing. Some industry
analysts have estimated that the number of connected devices and
systems (in an industrial, consumer, government, and business
setting) may rise from five billion devices to a trillion devices
over the next ten years.
[0003] A given cluster of devices may include upwards of hundreds
of thousands of devices or more. Persistence connectivity can be
used to lower the CPU and memory usage for a given connection,
which reduces the cost of such connectivity and is, particularly,
beneficial when there are such a vast number of connected devices.
Persistence connectivity generally refers to a single connection
between devices, which once established is used to send and receive
multiple requests/responses between the devices.
[0004] In one type of distributed computing architecture, one or
more business logic servers (referred to as a "platform servers")
are employed to service data and information for hundreds of
thousands or more computing devices. These servers may be
designated, for example, based on a given geographic region. For
example, a platform server may service a group of devices in North
America or the East Coast. The number of devices connecting to
these servers typically exceeds the resource capacity of such
servers. To this end, intermediary servers may be employed to
manage the connections between the computing devices and the
platform servers. Because of the potential benefit in efficiency
operation, persistent connectivity may reduce the number of
intermediary servers or platform servers necessary to provide data
service to a given number of computing devices.
[0005] When operating a load-balanced service, maintaining
information that must or should be kept across the multiple
requests in a user's session is useful. This information is
typically referred to as a session state. A common example of an
application that uses session state is a Web browser that uses
cookies. However, a typical persistence connections between two
network nodes use each other's network configuration. To this end,
multiplexing persistence connection may cause the state information
to be lost.
SUMMARY
[0006] In general overview, an intermediary party provides a
software library and computing architecture for building a
federation of distributed computing systems to service data for a
vast number of computing devices. To achieve connectivity to a
large number of devices, the federation generally includes multiple
server nodes to share the workload. The server nodes can be
logical/virtual or physical.
[0007] In some implementations, a platform server communicates to a
given computing device across one or more intermediary servers over
persistent connections. The platform routes data to and from data
storage servers and various back-end servers that provide services
to the computing devices. To this end, the intermediary servers
multiplex messages sent from an persistent connections established
with the edge servers to an persistent connection established with
the platform server.
[0008] To maintain these persistent connections, formed among the
devices within the federation while allowing a given computing
device to freely move within the system, the edge and intermediary
servers preferably operate using one or more non-network
addressable identifiers associated to a given computing device.
[0009] In some implementations, messages sent across the persistent
connections include a name identifier associated only with a given
computing system. This feature beneficially allows the computing
device to be serviced by the federation while being connected to
any edge server within the federation. To this end, the computing
device does not need to have any knowledge of the device's own
location or any networking or routing details about nodes within
the federation. The computing devices merely has to register, by
providing its name and a corresponding security key (in some
implementations), to a given edge server, to which the device is
automatically bound to a path within the federation.
[0010] In some implementations, the intermediary servers may
maintain and enforce authentication state for a given computing
device within the federation. The intermediary servers may maintain
the authentication state for a given session with a computing
device once the credentials of the computing device is verified. In
doing so, the platform server distributes the management of the
authentication session to the intermediary server while allowing
the platform to still perform the authentication.
[0011] In some implementations, the intermediary servers are
stateless connection managers in that the intermediary server does
not maintain state information of messages that it sends or
receives. To this end, data and information may be pipelined to
independently operating intermediary servers, which may, thus,
share connectivity work load with various intermediary servers.
[0012] Applications for the systems and methods described herein
are not limited to the aforementioned examples, but may be deployed
in any number of contexts, as would be understood by one of
ordinary skill in the art. Contents of the background are not to be
considered as an admission of the contents as prior art.
[0013] In one aspect, the present disclosure describes a method of
message routing using a name-based identifier in a distributed
computing environment. The method may include providing a platform
server, a set of intermediary servers, and a set of edge servers,
collectively defining a network where an end-point device
communicates to an edge server of the set of edge servers, the set
of edge servers communicates to the set of intermediary servers,
and the set of intermediary servers communicates to a platform
server.
[0014] In some implementations, the method may include binding, at
a platform server, at a first instance, the end-point device to the
platform server wherein the platform server binds, at the first
instance, the end-point device using a non-addressable name value
associated to the end-point device. The binding, at the first
instance, associates a first path across the network where the
first path is defined between the end-point device and the platform
server across one or more intermediary servers and one or more edge
servers.
[0015] In some implementations, the method may include
communicating, at the platform server, a first message to the
end-point device along the first path.
[0016] In some implementations, the method may include rebinding,
at the platform server, at a second instance, the end-point device
to the platform server where the platform server binds, at the
second instance the end-point device, using the non-addressable
name value associated to the end-point device. The non-addressable
name value may include a character string. The rebinding, at the
second instance, associates a second path across the network where
the second path is defined between the end-point device and the
platform server across one or more intermediary servers and one or
more edge servers, including a second intermediary server.
[0017] In some implementations, the method may include
communicating, at the platform server, a second message to the
end-point device along the second path. Each of the first path and
the second path may include a connection handle to an established
persistent connection. The established persistent connection may
include a WebSocket connection. At least one of the first path and
the second path may include at least two intermediary servers.
[0018] In some implementations, the method may include receiving,
at the platform server, at a given instance between the first and
second instances, a request to unbind the end-point device from the
platform server where the platform server unbinds the end-point
device based on the unbind request and where the unbinding
dissociates the first path defined between the end-point device and
the platform server.
[0019] In some implementations, the method may include binding, at
the platform server, at the first instance, a second end-point
device to the platform server where the platform server binds, at
the first instance, the second end-point device based on a second
non-addressable name value associated to the second end-point
device. The binding of the first end-point device and the binding
of the second end-point device may be the result of a single bind
request.
[0020] In one aspect, the present disclosure describes a system
including a processor and a memory, the memory storing instruction
that, when executed by the processor, cause the processor to bind,
at a first instance, the end-point device using a non-addressable
name value associated to the end-point device. The binding, at the
first instance, associates a first path across the network where
the first path is defined between the end-point device and the
bound server across one or more intermediary servers and one or
more edge servers.
[0021] In some implementations, the instructions, when executed,
further cause the processor to communicate a first message to the
end-point device along the first path.
[0022] In some implementations, the instructions, when executed,
further cause the processor to rebind at a second instance using
the non-addressable name value associated to the end-point device.
The non-addressable name value may include a character string. The
rebinding, at the second instance, associates a second path across
the network where the second path is defined between the end-point
device and the bound server across one or more intermediary servers
and one or more edge servers.
[0023] In some implementations, the instructions, when executed,
further cause the processor to communicate a second message to the
end-point device along the second path. Each of the first path and
the second path may include a connection handle to an established
persistent connection. The established persistent connection may
include a WebSocket connection. At least one of the first path and
the second path may include at least two intermediary servers.
[0024] In some implementations, the instructions, when executed,
further cause the processor to receive a request to unbind the
end-point device from the bound server based on the unbind request
where the unbinding dissociates the first path defined between the
end-point device and the bound server.
[0025] In one aspect, the present disclosure describes a
non-transitory computer readable medium having instructions stored
thereon, where the instructions, when executed by a processor,
cause the processor to bind, at a first instance, the end-point
device using a non-addressable name value associated to the
end-point device. The binding, at the first instance, associates a
first path across the network where the first path is defined
between the end-point device and the bound server across one or
more intermediary servers and one or more edge servers.
[0026] In some implementations, the instructions, when executed,
further cause the processor to communicate a first message to the
end-point device along the first path.
[0027] In some implementations, the instructions, when executed,
further cause the processor to rebind at a second instance using
the non-addressable name value associated to the end-point device.
The non-addressable name value may include a character string. The
rebinding, at the second instance, associates a second path across
the network where the second path is defined between the end-point
device and the bound server across one or more intermediary servers
and one or more edge servers.
[0028] In some implementations, the instructions, when executed,
further cause the processor to communicate a second message to the
end-point device along the second path. Each of the first path and
the second path may include a connection handle to an established
persistent connection. The established persistent connection may
include a WebSocket connection. At least one of the first path and
the second path may include at least two intermediary servers.
[0029] In some implementations, the instructions, when executed,
further cause the processor to receive a request to unbind the
end-point device from the bound server based on the unbind request
where the unbinding dissociates the first path defined between the
end-point device and the bound server.
[0030] In one aspect, the present disclosure describes a method of
routing messages in a distributed computing environment between a
platform server and an end-point device. The method may include
providing a platform server and one or more intermediate servers
where each of the intermediate servers connects and maintains a
persistent connection to the platform server and where the
intermediate servers communicate and maintain a number of
persistent connections with a number of edge servers. The
intermediate server may not maintain state information associated
with message content embedded within the given message.
[0031] In some implementations, the method may include receiving,
by a port at a given intermediate server, a service request from a
given edge server of the edge servers over a first persistent
connection.
[0032] In some implementations, the method may include inserting,
by the processor at the intermediate server, a given state
identifier to the service request where the given state identifier
is associated to a connection identity of the first persistent
connection and where the association is stored in memory at the
intermediate server.
[0033] In some implementations, the method may include
transmitting, at the intermediate server, the service request to
the platform server over a second persistent connection.
[0034] In some implementations, the method may include receiving,
at the intermediate server, a response message over the second
persistent connection, the response message having been generated
by the platform server in response to the service request where the
response message includes the given state identifier.
[0035] In some implementations, the method may include retrieving,
at the intermediate server, the connection identity of the first
persistent connection using the given state identifier where the
given state identifier is the same state identifier transmitted
within the service request. The given state identifier may be
inserted into a header portion of the service request.
[0036] In some implementations, the method may include routing, at
the intermediate server, the response message to a selected
connection of the persistent connections with the edge servers
where the selected connection is based on the retrieved connection
identity. The persistent connections may be Web-Socket
connections.
[0037] In some implementations, the intermediate server may
maintain, in the memory, a second state identifier associated with
an authentication exchange having been conducted between the
computing device connected to the given edge server and the
platform server. The second state identifier may be associated with
a name value associated with that of the computing device. In such
implementation, the method may include comparing, using the
processor at the intermediate server, a device identifier located
within the service request to the name value. If there is a match,
the intermediate server may inject the second state identifier into
the service request where the device identifier is associated with
an identity of a given computing device operatively communicating
with the given edge server. If the comparison is not a match, the
intermediate server may send an unbind request to the given edge
server where the unbind request causes the device identifier to be
removed from a binding list of one or more device identifiers
stored at the edge server. The second state identifier may be
associated to the connection identity of the first persistent
connection and where the association is stored in memory at the
intermediate server.
[0038] In one aspect, the present disclosure describes a system,
namely an intermediate server, including a processor and a memory,
the memory storing instruction that, when executed by the
processor, cause the processor to receive, by a port, a service
request from a given edge server over a first persistent
connection.
[0039] In some implementations, the instructions, when executed,
further cause the processor to insert a given state identifier to
the service request where the given state identifier is associated
to a connection identity of the first persistent connection and
where the association is stored in memory at the intermediate
server.
[0040] In some implementations, the instructions, when executed,
further cause the processor to transmit the service request to the
platform server over a second persistent connection.
[0041] In some implementations, the instructions, when executed,
further cause the processor to receive a response message over the
second persistent connection, the response message having been
generated by the platform server in response to the service request
where the response message includes the given state identifier.
[0042] In some implementations, the instructions, when executed,
further cause the processor to retrieve, at the intermediate
server, the connection identity of the first persistent connection
using the given state identifier where the given state identifier
is the same state identifier transmitted within the service
request. The given state identifier may be inserted into a header
portion of the service request.
[0043] In some implementations, the instructions, when executed,
further cause the processor to route the response message to a
selected connection of the persistent connections with the edge
servers where the selected connection is based on the retrieved
connection identity. The persistent connections may be Web-Socket
connections.
[0044] In some implementations, the intermediate server may
maintain, in the memory, a second state identifier associated with
an authentication exchange having been conducted between the
computing device connected to the given edge server and the
platform server. The second state identifier may be associated with
a name value associated with that of the computing device. In such
implementation, the intermediate server may compare, by the
processor, a device identifier located within the service request
to the name value. If there is a match, the intermediate server may
inject the second state identifier into the service request where
the device identifier is associated with an identity of a given
computing device operatively communicating with the given edge
server. If the comparison is not a match, the intermediate server
may send an unbind request to the given edge server where the
unbind request causes the device identifier to be removed from a
binding list of one or more device identifiers stored at the edge
server. The second state identifier may be associated to the
connection identity of the first persistent connection and where
the association is stored in memory at the intermediate server.
[0045] In one aspect, the present disclosure describes a
non-transitory computer readable medium having instructions stored
thereon, where the instructions, when executed by a processor,
cause the processor to receive, by a port, a service request from a
given edge server over a first persistent connection.
[0046] In some implementations, the instructions, when executed,
further cause the processor to insert a given state identifier to
the service request where the given state identifier is associated
to a connection identity of the first persistent connection and
where the association is stored in memory at the intermediate
server.
[0047] In some implementations, the instructions, when executed,
further cause the processor to transmit the service request to the
platform server over a second persistent connection.
[0048] In some implementations, the instructions, when executed,
further cause the processor to receive a response message over the
second persistent connection, the response message having been
generated by the platform server in response to the service request
where the response message includes the given state identifier.
[0049] In some implementations, the instructions, when executed,
further cause the processor to retrieve, at the intermediate
server, the connection identity of the first persistent connection
using the given state identifier where the given state identifier
is the same state identifier transmitted within the service
request. The given state identifier may be inserted into a header
portion of the service request.
[0050] In some implementations, the instructions, when executed,
further cause the processor to route the response message to a
selected connection of the persistent connections with the edge
servers where the selected connection is based on the retrieved
connection identity. The persistent connections may be Web-Socket
connections.
[0051] In some implementations, the intermediate server may
maintain, in the memory, a second state identifier associated with
an authentication exchange having been conducted between the
computing device connected to the given edge server and the
platform server. The second state identifier may be associated with
a name value associated with that of the computing device. In such
implementation, the intermediate server may compare, by the
processor, a device identifier located within the service request
to the name value. If there is a match, the intermediate server may
inject the second state identifier into the service request where
the device identifier is associated with an identity of a given
computing device operatively communicating with the given edge
server. If the comparison is not a match, the intermediate server
may send an unbind request to the given edge server where the
unbind request causes the device identifier to be removed from a
binding list of one or more device identifiers stored at the edge
server. The second state identifier may be associated to the
connection identity of the first persistent connection and where
the association is stored in memory at the intermediate server.
[0052] In one aspect, the present disclosure describes a method of
routing message between a platform server and a plurality of
end-point device via a connection server in a distributed computing
environment. The method may include providing a platform server, a
set of intermediary servers, and a set of edge servers,
collectively defining a network where an end-point device
communicates to an edge server of the set of edge servers, the set
of edge servers communicates to the set of intermediary servers,
and the set of intermediary servers communicates to a platform
server.
[0053] In some implementations, the method may include receiving,
by a port at the platform server, a first data message from a first
end-point device over a first persistent connection where the first
data message has been routed through a first intermediate server
over a second persistent connection.
[0054] In some implementations, the method may include receiving,
by the port at the platform server, a second data message from a
second end-point device over a third persistent connection, wherein
the second data message has been routed through a second
intermediate server over a fourth persistent connection. The
persistent connections may include WebSocket.
[0055] In some implementations, the method may include servicing,
by a processor at the platform server, the first data message and
the second data message where each of the first intermediate server
and second intermediate server manages connectivity between the
end-point devices and the platform servers. Each of the first
intermediate server and second intermediate server may manage
authentication sessions between the end-point devices and the
platform servers. The platform server may service the first data
message and the second data message by routing the messages to an
back-office server selected from a group consisting of a
persistence server, a database server, a customer relationship
management (CRM) server, an enterprise resource planning (ERP)
server, an operation support system (OSS) server, a business
support system (BSS) server, and a data warehouse.
[0056] In one aspect, the present disclosure describes a system
including a processor and a memory, the memory storing instruction
that, when executed by the processor, cause the processor to
receive, by a port, a first data message from a first end-point
device over a first persistent connection where the first data
message has been routed through a first intermediate server over a
second persistent connection.
[0057] In some implementations, the instructions, when executed,
further cause the processor to receive, by the port, a second data
message from a second end-point device over a third persistent
connection, wherein the second data message has been routed through
a second intermediate server over a fourth persistent connection.
The persistent connections may include WebSocket.
[0058] In some implementations, the instructions, when executed,
further cause the processor to service the first data message and
the second data message where each of the first intermediate server
and second intermediate server manages connectivity between the
end-point devices and the platform servers. Each of the first
intermediate server and second intermediate server may manage
authentication sessions between the end-point devices and the
platform servers. The platform server may service the first data
message and the second data message by routing the messages to an
back-office server selected from a group consisting of a
persistence server, a database server, a customer relationship
management (CRM) server, an enterprise resource planning (ERP)
server, an operation support system (OSS) server, a business
support system (BSS) server, and a data warehouse.
[0059] In one aspect, the present disclosure describes a
non-transitory computer readable medium having instructions stored
thereon, where the instructions, when executed by a processor,
cause the processor to receive, by a port, a first data message
from a first end-point device over a first persistent connection
where the first data message has been routed through a first
intermediate server over a second persistent connection.
[0060] In some implementations, the instructions, when executed,
further cause the processor to receive, by the port, a second data
message from a second end-point device over a third persistent
connection, wherein the second data message has been routed through
a second intermediate server over a fourth persistent connection.
The persistent connections may include WebSocket.
[0061] In some implementations, the instructions, when executed,
further cause the processor to service the first data message and
the second data message where each of the first intermediate server
and second intermediate server manages connectivity between the
end-point devices and the platform servers. Each of the first
intermediate server and second intermediate server may manage
authentication sessions between the end-point devices and the
platform servers. The platform server may service the first data
message and the second data message by routing the messages to an
back-office server selected from a group consisting of a
persistence server, a database server, a customer relationship
management (CRM) server, an enterprise resource planning (ERP)
server, an operation support system (OSS) server, a business
support system (BSS) server, and a data warehouse.
BRIEF DESCRIPTION OF THE DRAWINGS
[0062] The foregoing and other objects, aspects, features, and
advantages of the present disclosure will become more apparent and
better understood by referring to the following description taken
in conjunction with the accompanying drawings, in which:
[0063] FIG. 1 is a block diagram of an example system for enabling
communication between a platform server and a plurality of
computing devices in accordance with an embodiment of the
invention.
[0064] FIG. 2 is a block diagram of an example
persistent-communication channels established between a given
platform server and a given computing device in accordance with an
embodiment of the invention.
[0065] FIG. 3 is an example of a messaging structure of the
communication API protocol in accordance with an embodiment of the
invention.
[0066] FIG. 4 illustrates example messaging code employed by the
communication API protocol in accordance with an embodiment of the
invention.
[0067] FIG. 5 is a swim-lane diagram of an example method of
injecting state and routing information into a communication
exchange between a platform server and an end-point device over a
stateless persistent connection in accordance with an embodiment of
the invention.
[0068] FIG. 6 is a swim-lane diagram of the method of injecting
state and routing information into a data-request
communication-exchange between a platform server and an end-point
device over a stateless persistent connection in accordance with an
embodiment of the invention.
[0069] FIG. 7 is a flow chart for an example method of controlling
a connection server in accordance with an embodiment of the
invention.
[0070] FIG. 8 illustrates a method of rebinding a persistent
connection path for a computing device in accordance with an
embodiment of the invention
[0071] FIG. 9 is a block diagram of an example system in accordance
with an embodiment of the invention.
[0072] FIG. 10 is a flowchart of an example method of injecting
state and routing information into a communication exchange between
a platform server and an end-point device over a stateless
persistent connection in accordance with an embodiment of the
invention.
[0073] FIG. 11 is a flowchart of an example method of communication
between two network nodes and an intermediary node over a
persistent connection in accordance with an embodiment of the
invention.
[0074] FIG. 12 is a flow chart of an example method 1202 of
communication between the platform server and a plurality of an
end-point device in accordance with an embodiment of the
invention.
[0075] FIG. 13 is a block diagram of a computing device and a
mobile computing device.
[0076] The features and advantages of the present disclosure will
become more apparent from the detailed description set forth below
when taken in conjunction with the drawings, in which like
reference characters identify corresponding elements throughout. In
the drawings, like reference numbers generally indicate identical,
functionally similar, and/or structurally similar elements.
DETAILED DESCRIPTION
[0077] FIG. 1 is a block diagram of an example system 100 for
enabling communication between a platform server 102 and a
plurality of computing devices 104 in accordance with an embodiment
of the invention. Each of the computing devices 104 connects to an
edge server 106 that services and maintains communication with a
group of computing devices 108. A computing device 104, in some
examples, is an electronic device that can communicate properties-,
services-, and events-data and information relating to physical
assets/devices, computer applications and systems, people, data
objects, and platform services.
[0078] In some implementations, the computing device 104 is a
sensor or a machinery at an industrial complex; a computer or an
office equipment at a business or government office; a
point-of-sale machine at a market place or a vending machine; a
construction equipment or a vehicle; a power generation or
distribution equipment; a power substation or transmission
equipment; a building meter; a server; a networking or routing
equipment; a smart appliance; an exercise machine; a medical device
or a prosthesis device; a medical diagnostic device or a hospital
equipment; a commercial vehicle or a transport container; a motor
vehicle or an electric bicycle; a cellphone, a laptop, a tablet, an
electronic reader; or a clothing electronic-tag.
[0079] An edge server, in some implementations, is an electronic
device that has communication ports to interface to the endpoint
device. The edge server may be, for example, but not limited to, a
gateway device, a network server, a single board computer, a
supervisory control and data acquisition system ("SCADA"), or a
programmable logic controller ("PLC") The edge server may
communicate to the endpoint device by industrial, commercial,
computing, and military physical connection standards. These
standards may include, for example, but not limited to, Modbus,
RS-232, RS-422, RS-485, Serial-ATA, SCSI, FireWire (IEEE 1394),
Ethernet, Universal Serial Bus, SONET ("Synchronous Optical
Networking"), MIL-STD-1553, I.sup.2C ("Inter-Integrated Circuit"),
CAN-bus ("controller area network"), ARINC 739 ("Avionics Digital
Video Bus"), BACnet, LonWorks. The standards may also include
health/medical communication standards, such as CEN ISO/IEEE 11073.
The examples are merely for illustrative purposes. To this end,
other types of standards may also be employed.
[0080] To serve data and information for sets of computing devices
104, one or more edge servers 106 may communicate to an
intermediary server, referred to as a connection server 110 or an
"API server 110", over a first persistent connection 103. The
connection server 110, in turn, communicates to the platform server
102 over a second persistent connection 105. In essence, the
connection server 110 form a persistent path between the platform
server 102 and a given edge server 106 across the first persistent
connection 103 and the second persistent connection 105.
[0081] Collectively, the platform servers 102, the connection
servers 110, and the edge servers 106 form a federation of
distributed computing systems. In some implementations, the
platform servers 102 are business logic servers that maintain
connectivity to a given computing device 104. In such instances,
the platform server 102 may communicate to various back-office
servers that provide service functions, such as searching, storing,
and managing, among others, for the data and information of the
computing device 104. To this end, the platform server 102 may
merely serve to route data to and from various applications and
systems with the computing devices 104.
[0082] In some implementations, the platform server 102 may manage
the authentication process of the computing devices 104.
[0083] In some implementations, the platform server 102 routes data
to and from the various back-office applications and systems. For
example, when data is received from a specific computing device
104, the platform server 102 may route the data to another database
server. In other embodiments, a third party application may request
the data to be sent by the platform server.
[0084] Back-office servers may include, for example, third-party
products for CRM/ERP ("customer relationship management" and/or
"enterprise resource planning"), data analytics, Big Data Store
(such as Hadoop, Data Warehouses, and various distributed file
systems), identity management, billing, provisioning, and providing
Web service. Examples of such back-office systems may include
SAP.RTM. Enterprise Resource Planning "ERP", Salesforce.RTM.
Customer Relationship Management "CRM", Operations Support System
"OSS", and Business Support Systems "BSS" Components.
[0085] Various data storage and applications may communicate with
the platform server 102. In some implementations, this
communication may be by way of Web Services, Java Database
Connectivity (JDBC), or native APIs.
[0086] In some implementations, the communication exchange between
the connection servers 110 and the edge servers 106 occurs across a
network infrastructure 112, such as the Internet 112a, a Wide-area
network 112b, or a third-party network 112c. In turn, one or more
connection servers 110 communicate to the platform server 102. The
platform server 102, the connection servers 110, and the edge
servers 106, collectively, forms a distributed computing system. In
some implementations, a given connection server 110 communicates to
a set of edge servers 106 through a set of network security
equipment 114. The security equipment secures the connection server
110 and platform server 102 from the open network infrastructure
112. It also secures the groups of edge servers 106 and computing
devices 104 from the same. The network security equipment 114 may
include, for example, a firewall or Network Address Translation
(NAT) protocol.
[0087] FIG. 2 is a block diagram of an example persistent
communication channel 200 established between a given platform
server 102 and a given computing device 104 in accordance with an
embodiment of the invention.
[0088] The platform server 102 runs a server-client application
using an API protocol library 204a that manages the communication
over the channel 200. The edge server 106 runs a server-client
application 204c that runs the same communication API protocol
library 204. To this end, messages being communicated inbound and
outbound between the platform server 102 and the edge servers 106
are, for the most part, symmetrical in that these messages share
the same message structure.
[0089] In some implementations, the API protocol library 204 is a
binary Dynamic REST API. Examples of methods of communicating using
the binary Dynamic REST APIs are described in co-pending and
concurrently filed U.S. patent application, titled "SYSTEM AND
METHOD OF USING BINARY DYNAMIC REST MESSAGES", filed Mar. 21, 2014,
naming inventors Rick Bullotta, John Canosa, Bob DeRemer, and Mike
Mahoney, and having attorney docket no. 2009132-0035. This
application is incorporated by reference in their entirety.
[0090] This symmetry is intended to reduce the complexity of
operation of the connection server 110 as the connection server 110
can generally service each communicated message in the same manner
without much regard to the source or target.
[0091] In some implementations, the communication API protocol
generates each message with metadata relating to the connection.
The connection server 110 may use the connection metadata to
preserve state information at both the edge server 106 and the
platform server 102. To this end, the state information for a given
edge server 106 and a given platform server 102 is communicated
within each message allowing the servers to be stateless. In some
implementations, the connection metadata merely may include a
message identifier, authentication state information, and routing
information associated with a given persistent connection.
[0092] FIG. 3 is an example message structure 300 of the
communication API protocol 204 in accordance with an embodiment of
the invention. The message structure 300 may include both a header
302 that provides the connection metadata and a body 304 that
provides the message content.
[0093] In some implementations, the header 302 may include a
session identification number 308, referred to as a "SessionId
308." The session identification number is preferably associated to
both a given name identifier of an end-point device and a
connection handle of a persistent connection. The association may
be used by the connection server 110 to determine a binding path of
a given computing device 104. The connection server 110 may use the
session identification number to manage authentication session
state on behalf of the platform server 102.
[0094] In some implementations, the connection server 204 may
generate the session identification number 308 during an
authentication process associated with a given computing device
104. During the process, the connection 204 stores the session
identification number 308 and the communication handle from which
the message was received. In some implementations, the session
identification number 308 is preferably a 32-digit long binary
number with the most-significant digit (MSB) first, though it can
be of various data length and endian.
[0095] In some implementations, the header 302 may include an
endpoint identification number 310, referred to as an "EndPointId
310", that is associated to a given persistent connection 202. The
connection server can subsequently retrieve the connection handle
using the endpoint identification number 310. The endpoint
identification number 310 is preferably a 32-digit long binary
number with the most-significant digit (MSB) first. The connection
server 110 may use the endpoint identification number to preserve
routing state information lost due to the multiplexing of the
persistent connection.
[0096] The header 302 may include other information fields to
improve the operational efficiency of the messaging protocol. In
some implementations, the header 302 may include a request
identification number 306, referred to as a "RequestId 306," that
is associated to a given message. The request identification number
306 may be randomly generated or incrementally generated to be
unique for a given persistent communication channel 200. The
request identification number 306 may be employed to determine
whether a service request has been fulfilled. In some
implementations, the request identification number 306 is
preferably a 24-digit long binary number with the most-significant
digit (MSB) first, though it can be of various data length and
endian.
[0097] In some implementations, the header 302 may include a
message type field 312, referred to as a "Method code 312." The
message field may include codes to allow for the quick
identification of the type of message being received. For simple
messages, such as an acknowledgement or error message, the message
type field 312 may constitute the message. For request messages,
the message type field 312 may include a code corresponding to a
type of request. In some implementations, the request type message
may be based on an HTTP framework.
[0098] In some implementations, the header 302 may include a
multi-part message field 314, referred to as "Multipart 314." This
field may be used to identify whether the message is a part of a
group of message having the same request identification number 306.
The header identification number 316 is preferably a 8-bit
number.
[0099] FIG. 4 illustrates example message codes employed by the
communication API protocol in accordance with an embodiment of the
invention. The codes include HTTP-based request messages 318,
HTTP-based success codes 320, HTTP-based server-error codes 322,
and HTTP-based client-error codes 324.
[0100] In an aspect of an embodiment of the invention, the
connection server 110 injects routing state information to an
inbound message being sent to the platform server 102. The
inventors have found that injecting state information over a
stateless connection improves performance of the connection over
typical stateful connections.
[0101] In having the routing state information embedded within each
message, the connection server can complete a roundtrip message
transfer, in some implementations, using merely a lookup of the
connection handle associated with the routing state identifier.
[0102] In another aspect of an embodiment of the invention, the
connection server 110 injects the authentication state information
to an inbound message being sent to the platform server 102. In
having the session state embedded within the message, the
connection server 110 takes over the managing of the authentication
session, thus freeing resources for the platform server, preferably
to manage more devices.
[0103] FIG. 5 is a swim-lane diagram of an example method 500 of
injecting state and routing information into a communication
exchange between a platform server 102 and an end-point device 104
over a multiplexed stateless persistent connection in accordance
with an embodiment of the invention.
[0104] The method 500, in some implementations, begins with a
computing device 104 (referred to as endpoint device "D1")
registering with an edge server 106 (referred to as edge server
"E1") (step 501a). In some implementations, the registration may be
a handshake or some automated process of negotiation to establish
communication between the endpoint device "D1" and the edge server
"E1". The edge server "E1" is an electronic device that has
communication ports to interface to the endpoint device D1.
[0105] The edge server "E1", which is executing a client-side
application using the API protocol library 204, prepares (step
502a) an authentication request message 502b in accordance, for
example, with the request message structure as described in
relation to FIGS. 3 and 4. The request message 502b may include a
"RequestId R1" (shown as "R1") corresponding to the request
identification number 306, as described in relation to FIG. 3. The
edge server "E1" (106) then sends (step 502c) the authentication
request message 502b to the connection server 110 over a first
persistent connection established between the edge server "E1"
(106) and the connection server "A1" (110).
[0106] The body of the message, in some implementations may include
an authentication message (shown as "<Auth>"). The
authentication message may include an authentication name and a
corresponding authentication password. In some implementations, the
authentication name may be the name identifier of the edge server
"E1" (106). The name identifier may be random or descriptive. The
name identifier may have some reference to the owner and type of
device. For example, an electrocardiogram device no. 123 owned by
the John Doe Medical Institute may have a descriptive name
identifier of "JohnDMedInt_EKG_Dev_123."
[0107] In some implementations, the authentication name and the
corresponding security code may be in an UTF8 data-type string
("Unicode Standard--8 bits"). The string may be of any length and
may be preceded, in the message, by a length value corresponding to
the string length in the UTF8 format. The corresponding security
code may, for example, be a password, such as "GoodPassWord123". Of
course, various values and length may be employed. In other
implementations, the authentication message may be a security key,
which can be an encrypted data string generated using a token
associated with a name identifier of the edge server "E1". Various
conventional authentication techniques may be employed.
[0108] In some implementations, the edge server "E1" (106) may
require a second set of authentication credentials in addition to
the authentication name and corresponding authentication password
used in the authentication message. The second set of
authentication credentials may be specific to the edge server "E1"
(106) to prevent a non-authenticated computing devices from binding
with it and may be employed.
[0109] Still referring to FIG. 5, upon receiving the authentication
request message 502b, in some implementations, the connection
server "A1" (110) injects (step 502d) "SessionId S1" (shown in FIG.
5 as "s1") and "EndpointId e1" (shown as "e1") into the received
message 502b to produce message 502e. The connection server "A1"
(110) then sends (step 502f) the message 502e to the platform
server 102, referred to as the platform server "P1" (102), over a
second persistent connection established between the connection
server "A1" (110) and the platform server "P1" (102). The
"EndpointId e1" may correspond to the endpoint identification
number 310, as described in relation to FIG. 3, that is associated
to the first persistent connection. The "SessionId s1" may
correspond to the session identification number, as also described
in relation to FIG. 3, that is associated to a given persistent
connection and the name identifier belonging to the endpoint device
D1 (104).
[0110] In some implementations, the received message 502b has a
NULL or EMPTY value in the header fields 306 and 308. To this end,
the "SessionId s1" and the "EndpointId e1" can merely replace the
values there. In other implementations, the received message 502b
is concatenated with the "SessionId s1" and the "EndpointId e1". Of
course, various methods of injecting data into a data stream may be
employed.
[0111] Upon receiving the message 502e, the platform server "P1"
(102) processes (step 504a) the authentication request message. In
some implementations, the platform server "P1" (102) authenticates
the credentials of the endpoint device D1 (104) using an
authentication registry that it maintains. In some implementations,
the platform server "P1" (102) may route the message to a
back-office authentication-server (not shown) to perform the
authentication.
[0112] The platform server "P1" (102) then prepares a return
message 506b (step 506a). The return message 506b may be related to
the authentication process (for example, pass or not passed), or it
may be merely be an acknowledgement of receipt of the message (for
example, success receipt or receipt error). To this end, the return
message 506b may be a status code, as described in relation to FIG.
4.
[0113] In some implementations, the platform server 102 prepares
the return message 506b to include the "RequestId R1", the
"SessionId s1", and the "EndpointId e1" as received in the request
message 502e. In essence, the platform server "P1" (102) merely
employs the metadata information of the received message to produce
a return message, which may be an indicia of acknowledgement or
success. The platform server "P1" (102) then sends the message 506b
(step 506c) to the connection server 110 over the second persistent
connection.
[0114] Upon receiving the message 506b, in some implementations,
the connection server "A1" (110) may use the "EndPointId e1" to
identify the connection to forward the message 506b (step 506d) to
the Edge Server "E1" (106). To this end, no additional processing
may be necessary to be performed at the connection server "A1"
(110). In some implementations, the "EndPointId e1" may be indexed
to the connection handle associated with the persistent connection.
The index may have been stored at the connection server "A1" (110)
within a hash table.
[0115] To this end, preserving state information for a roundtrip
routing through a multiplexed persistent connection paradigm may
collectively employ a single hash-table lookup of an identifier
associated with a given persistent connection, a single write
function to inject in the identifier into a message header, and a
single read of the message header to retrieve the communication
handle to the same persistent connection.
[0116] Referring still to FIG. 5, in some implementations,
subsequent to an authentication exchange, the edge server "E1"
(106) initiates a binding process. The binding process binds a path
between the end-point device "D1" (104) and the platform server
"P1" (102). At each node along the path, the binding process
associates a connection handle of a persistent connection that
points to the end-point device.
[0117] The binding process is synergistic with the usage of routing
metadata. Routing metadata may allow for messages from the platform
server to be quickly and efficiently returned to the end-point
device.
[0118] In some implementations, the edge server "E1" (106) prepares
a binding message 508a and sends the message 508b (step 508c) to
the connection server "A1" (110) across the first persistent
connection. The edge server "E1" (106) generates a "requestId R2".
In some implementations, the request message 508b may include a
"BIND" request code, as described in relation to FIG. 4 and as
shown as "B" in message 508b. The payload of the request message
508b may include the name identifier of the endpoint device "D1"
(104).
[0119] Upon receiving the bind request message 508b, in some
implementations, the connection server "A1" (110) injects (step
508d) "SessionId S1" (shown in FIG. 5 as "s1") and "EndpointId e1"
(shown as "e1") into the received message 508b to produce message
508e.
[0120] Additionally, the connection server "A1" (110) determines
that the received message is a bind request. To this end, it adds
the name identifier located within the payload 304 to its binding
registry. In the registry, the name identifier may be associated
with a connection handle of the first persistent connection. For
example, the name identifier is used as an index value in a hash
table having the connection handle.
[0121] The connection server "A1" (110) then sends (step 508f) the
bind request message 508e to the platform server "P1" (102), over a
second persistent connection.
[0122] Upon receiving the message 508e, in some implementations,
the platform server "P1" (102) processes the bind request (step
510a). For example, it may add the name identifier to its binding
registry.
[0123] In some implementations, the platform server "P1" (102)
prepares a success message 512b (step 512a). The platform server
"P1" (102) sends the success message 512b (step 512c) to the
connection server "A1" (110) over the second persistent connection.
Upon receiving the message 512b, the connection server "A1" (110)
may use the "EndPointId e1" to identify the connection. The
connection server "A1" (110) forwards the message 512e (step 512d)
to the edge server "E1" (106).
[0124] In some implementations, the edge server "E1" (106) may send
a message to the endpoint device "D1" (104) to acknowledge a
successful registration process.
[0125] FIG. 6 is a swim-lane diagram of the method 600 of
communicating from the platform server 102 over a stateless
persistent connection in accordance with an embodiment of the
invention.
[0126] The method 600, in some implementations, begins with the
platform server "P1" (102) preparing a request message 606b (step
606a) for the edge server "E1" (106).
[0127] The platform server "P1" (102) sends the request message
606b to the connection server "A1" (110) over the second persistent
connection using a connection handle determined from its binding
registry.
[0128] Upon receiving the message 606b, in some implementations,
the connection server "D1" (110) determines that the message is an
outbound message from the platform server "P1" (102). This
determination may be based on the connection handle of the second
persistent connection, or it may be based on the presence of a
session identification number 308 within the message 606b. The
connection server "D1" (110) may inject an "EndpointId e2"
associated with the received connection handle for the second
persistent connection (step 606d). The connection server "D1" (110)
may identify the appropriate persistent connection for the message
606b using the name identifier in the message 606b and a
corresponding connection handle stored in its binding registry. The
connection server "D1" (110) then forwards the message 606e to the
appropriate edge server "E1" (106) using the identified handle.
[0129] Upon receiving the message 606e, in some implementations,
the edge server "E1" (106) sends back a success/acknowledge message
610a (step 610a) to the connection server "A1" (110) over the same
persistent connection, namely the first persistent connection. The
edge server "E1" (106) uses the requested data in the message's
payload 304 (step 608a) and removes the data service request from
its queue. The edge server "E1" (106) may generate a success
message (step 608a) and sends to the connection server "A1" across
the first persistent connection.
[0130] The connection server "A1" (110) receives the message 610a
and relays the message to the platform server "P1" (102) over the
second persistent connection using the "endPointId e2". Upon
receiving the acknowledgment message 610a, in some implementations,
the platform server "P1" (102) removes the request message from its
queue.
[0131] FIG. 7 is a flow chart for an example method 700 of
controlling a connection server 110 in accordance with an
embodiment of the invention. In some implementations, the controls
are based on policies that are executed from a client-side
application operating at the connection servers 110. A policy may
include, for example, rule-base methodology, a state machine, a
model-based control, and/or a sequential logic.
[0132] Upon receiving a message (step 702), the connection server
110 determines whether an endpoint identification number 310 is
present in the message (step 704), as described in relation to
FIGS. 5 and 6. In some implementations, the endpoint identification
number 310 is located in a fixed field within the message header
302. In other implementations, the connection server 110 may parse
the message for the information. If an endpointId 310 is in the
message, then the connection server 102 may route the message using
the endpointId 310, as described in relation to FIGS. 3, 5, and
6.
[0133] If the endpointId 310 is NULL or empty, the connection
server 110 may inject an identification number associated with a
connection handle associated to the channel that the id was
received.
[0134] The connection server 110 may then check the message method
code 312 to determine the message type (step 710, 718, 724).
[0135] If the message type is an authentication message (step 710),
the connection server 110 may inject the session identification
number 308 into the message (step 712), as described in relation to
FIGS. 5 and 6. The connection server 110 may bind the endpointId
310, the sessionId 308 and the connection (step 714), as described
in relation to FIG. 5, and forward the message to the platform
server 102 (step 716).
[0136] If the message type is a bind or unbind message (step 718),
the connection server 110 may bind the name identifier located in
the message to its binding registry (or remove the name identifier
in the message from its binding registry) (step 720) and forward
the message to the platform server 102 (step 722).
[0137] If the message type is a request message (step 724), the
connection server 110 may merely forward the request message to the
platform server 102 (step 726).
[0138] The connection server 110 may then check the request message
to determine whether the sessionId is present (step 728). If
present, the message may be routed to the respective edge server
106 using its binding registry to determine the appropriate
connection handle. If not present, the connection server 110 may
retrieve the SessionId using the nameId in the message (step 732),
inject the SessionId into the message (step 734), and forward the
message to the platform server (step 736).
[0139] FIG. 8 illustrates a method of binding and rebinding in
accordance with an embodiment of the invention. The binding allows
a given computing device 104 to be serviced by the federation while
being connected to any end-point device within the federation
without any knowledge of the device's own location or any
networking or routing details about nodes within the federation. To
this end, the federation allows messages from the computing device
to freely route to the platform server regardless of the
intermediate servers over this persistent-connection
architecture.
[0140] The method initiates with a given computing device 104,
namely the end-point device 104a, being registered, as described in
relation to FIG. 5, with edge server 106a. The edge server 106
sends a bind request to a connection server 110a over persistent
connection 103a. The bind request may include a name identifier of
the end-point device 104 in the binding list. The connection server
110a forwards the bind request to the platform server 802 over
persistent connection 105a. The connection server 110a also
associates the end-point device 104a with the persistent connection
103a and stores the association in its binding registry. The
association may be based on the connection handle of the persistent
connection. The binding registry may be a data table or a hash
table. The platform server 102a associates the end-point device
104a with persistent connection 105a and stores the association in
its binding registry. To this end, when sending a request message
to end-point device 104a, the platform server 102 retrieves the
persistent connection 105 associated to the end-point device
104a.
[0141] Subsequent to binding, if the end-point device 106a moves to
another edge server, namely edge server 106c, the end-point device
106a would de-register with the edge server 106a. The edge server
106a would send an unbind request to the primary server 102a
through the bounded path (103a, 105a). The unbind request would
remove the end-point device 106a from the binding registry of the
connection server 110a and the platform server 102. The end-point
device 106a would then register with the edge-server 106c and
repeat the same binding process.
[0142] FIG. 9 is a block diagram of a network 900 using the system
100 in accordance with an embodiment of the invention. The network
900 may include back-end office components, as described in FIG.
2.
[0143] In some implementations, the network 900 may include one or
more persistent servers 902. The persistence servers can share the
load from data being sent to the platform server 102, shown as
routing servers 102. The persistence servers 902 may employ
specific types of persistence objects, such as Streams and
DataTable. Examples of Streams and DataTable are described in U.S.
patent application Ser. No. 13/678,885, titled "METHODS FOR
DYNAMICALLY GENERATING APPLICATION INTERFACE FOR MODELED ENTITY AND
DEVICES THEREOF," filed Nov. 16, 2012. The application is
incorporated by reference herein in its entirety.
[0144] In some implementations, the network 900 may include one or
more back-office servers 904, such as CRM/ERP, including various
servers as described in relation to FIG. 2. In some
implementations, the network 900 may include one or more Big Data
and Data Store 906. Such servers 906 may communicate to the
platform server 102 using Web protocols, such as Java Database
Connectivity (JDBC) or native APIs. In some implementations, the
platform server 102 may process an event to route the data to the
appropriate database when data is received from a given computing
device 104. Alternatively, a third party application may initiate
an event.
[0145] FIG. 10 is a flowchart of an example method 1000 of
injecting the state and routing information into a communication
exchange between a platform server 102 and an end-point device 104
over a stateless persistent connection in accordance with an
embodiment of the invention. An example of a stateless persistent
connection is a Web-Socket connection. The end-point device may be
the edge server 106 or the computing device 104. The method 1000
may include providing one or more platform servers 102 connected to
one or more intermediate servers 110. Each of the intermediate
servers 110 may connect and maintain a persistent connection 200a
to the platform server 102. The intermediate servers 102 may also
communicate and maintain a number of unique persistent connections
200b with a plurality of edge servers.
[0146] In some implementations, a port at a given intermediate
server 110 receives a service request from a given edge server 106
over a first persistent connection 200b (step 1002). The processor,
at the intermediate server 110, inserts a session identifier to the
service request (step 1004). The session identifier is associated
to a connection identity of the first persistent connection. The
association is stored in memory at the intermediate server. The
intermediate server 110 is preferably "stateless" in that it does
not retain state information associated with a given request
message. In such implementations, the intermediate server 110
preferably does not maintain knowledge of whether a similar request
message has been previously sent and which of a sequence of message
action this message belongs thereto. Put another way, it forgets a
given message after having received and forwarded it along.
[0147] Such stateless paradigm may reduce the workload of the
intermediate server 110 as it can, thus, be configured to operate
with a fewer set of instructions and with lower memory usage
requirements. To this end, with less resource being required for a
given connection, a given intermediate server 110 can service more
numbers of computing devices 104 as compared to a comparable
hardware system that operates the additional overhead work of
maintaining such message state information. In some
implementations, the given session identifier is injected into a
header portion, such as the header 402, of each request
message.
[0148] The intermediate server may maintain, in the memory, a
second state identifier associated with an authentication session
of a computing device 104. The second state identifier may be
associated with a name value associated with the computing device
104. The second state identifier may also be associated to the
connection identity of the first persistent connection. The
association may be stored in the local memory of the intermediate
server 110. In some implementations, the intermediate server 110
may maintain the association in a hash table. The table may use
name value to index the second state identifier and a network
handle created when the persistent connection was established.
[0149] In some implementations, the name value is preferably a
non-network-based addressable identifier. Rather than a network
addressable identifiers, which can be for example a uniform
resource identifier (URI) or an Internet Protocol (IP) address, the
name value can be a number sequence or a character string.
[0150] In some implementations, the intermediate server 110
transmits the service request to the platform server 102 over a
second persistent connection (step 1006).
[0151] In some implementations, the intermediate server 110
receives a response message over the second persistent connection
200a. The response message may have been generated by the platform
server in response to the service request and may include the
session identifier (step 1008).
[0152] In some implementations, the intermediate server 110
retrieves the connection identity of the first persistent
connection using the session identifier (step 1010). The session
identifier is the same session identifier transmitted within the
service request.
[0153] In some implementations, the intermediate server 110 routes
the response message to a selected connection among the numbers of
persistent connections established with the edge servers (step
1012). The selected connection may be based on the retrieved
connection identity.
[0154] FIG. 11 is a flowchart of an example method 1100 of
communication between two network nodes and an intermediary node
over a persistent connection in accordance with an embodiment of
the invention. In some implementations, the method 1100 begins at
an initialized state at step 1102 where the two network nodes may
include the platform server 102 and an end-point device, namely the
computing device 104. The method 1100 may include providing one or
more platform servers 102 connected to one or more intermediate
servers 110. Each of the intermediate servers 110 may connect and
maintain a persistent connection 200a to the platform server 102.
The intermediate servers 102 may communicate and may maintain a
number of unique persistent connections 200b with a plurality of
edge servers 104.
[0155] In some implementations, the platform server 102 binds, at a
first time instance, the end-point device 104 to the platform
server 102 (step 1104). The binding, at the first instance, may
associate with a first path across the network. The first path may
be defined between the end-point device 104 and the platform server
102 across one or more intermediary servers and one or more edge
servers.
[0156] In some implementations, the platform server 102
communicates a first message to the end-point device 104 along the
first path (step 1106).
[0157] In some implementations, the platform server 102 rebinds, at
a second instance, the end-point device 104 to the platform server
102 (step 1108). This may occur after the end-point device 104 has
moved to an edge server different from the first path.
[0158] In some implementations, the platform server 102
communicates a second message to the end-point device along the
second path (step 1110). To this end, the end-point device can move
among different geographic locations without regard to its own
knowledge of its location. Rather, the network may discover a path
for message to flow to and from the platform server without any
knowledge on the part of the end-point device 104.
[0159] FIG. 12 is a flow chart of an example method 1200 of
communication between the platform server and a plurality of an
end-point device 104 in accordance with an embodiment of the
invention. In some implementations, the method 1200 begins at an
initialized state (step 1202). In some implementations, the
platform server 102 receives a first data message from a first
end-point device 104a over a first persistent connection 105a (step
1204). The first data message has been routed through a first
intermediate server 110a over a second persistent connection
103a.
[0160] In some implementations, the platform server 102 receives a
second data message from a second end-point device 104b over a
third persistent connection 105b (step 1206). The second data
message has been routed through a second intermediate server 110b
over a fourth persistent connection 103b.
[0161] Each of the first intermediate server 110a and second
intermediate server 110b may manage both the authentication
sessions and the connectivity between the end-point devices 104 and
the platform servers 102.
[0162] In some implementations, the platform server 102 services
the first data message and the second data message (step 1208). The
platform server 102 may service the first data message and the
second data message by routing the messages to a back-office
server. As described in relation to FIG. 2, the back-office server
may include, for example, a persistence server, a database server,
a customer relationship management (CRM) server, an enterprise
resource planning (ERP) server, an operation support system (OSS)
server, a business support system (BSS) server, or a data
warehouse.
[0163] FIG. 13 shows an example of a computing device 1300 and a
mobile computing device 1350 that can be used to implement the
techniques described in this disclosure. The computing device 1300
is intended to represent various forms of digital computers, such
as laptops, desktops, workstations, personal digital assistants,
servers, blade servers, mainframes, and other appropriate
computers. The mobile computing device 1350 is intended to
represent various forms of mobile devices, such as personal digital
assistants, cellular telephones, smart-phones, and other similar
computing devices. The components shown here, their connections and
relationships, and their functions, are meant to be examples only,
and are not meant to be limiting.
[0164] The computing device 1300 may include a processor 1302, a
memory 1304, a storage device 1306, a high-speed interface 1308
connecting to the memory 1304 and multiple high-speed expansion
ports 1310, and a low-speed interface 1312 connecting to a
low-speed expansion port 1314 and the storage device 1306. Each of
the processor 1302, the memory 1304, the storage device 1306, the
high-speed interface 1308, the high-speed expansion ports 1310, and
the low-speed interface 1312, are interconnected using various
busses, and may be mounted on a common motherboard or in other
manners as appropriate. The processor 1302 can process instructions
for execution within the computing device 1300, including
instructions stored in the memory 1304 or on the storage device
1306 to display graphical information for a GUI on an external
input/output device, such as a display 1316 coupled to the
high-speed interface 1308. In other implementations, multiple
processors and/or multiple buses may be used, as appropriate, along
with multiple memories and types of memory. Also, multiple
computing devices may be connected, with each device providing
portions of the necessary operations (e.g., as a server bank, a
group of blade servers, or a multi-processor system).
[0165] The memory 1304 stores information within the computing
device 1300. In some implementations, the memory 1304 is a volatile
memory unit or units. In some implementations, the memory 1304 is a
non-volatile memory unit or units. The memory 1304 may also be
another form of computer-readable medium, such as a magnetic or
optical disk.
[0166] The storage device 1306 is capable of providing mass storage
for the computing device 1300. In some implementations, the storage
device 1306 may be or contain a computer-readable medium, such as a
floppy disk device, a hard disk device, an optical disk device, or
a tape device, a flash memory or various solid state memory device,
or an array of devices, including devices in a storage area network
or various configurations. Instructions can be stored in an
information carrier. The instructions, when executed by one or more
processing devices (for example, processor 1302), perform one or
more methods, such as those described above. The instructions can
also be stored by one or more storage devices such as computer- or
machine-readable mediums (for example, the memory 1304, the storage
device 1306, or memory on the processor 1302).
[0167] The high-speed interface 1308 manages bandwidth-intensive
operations for the computing device 1300, while the low-speed
interface 1312 manages lower bandwidth-intensive operations. Such
allocation of functions is an example only. In some
implementations, the high-speed interface 1308 is coupled to the
memory 1304, the display 1316 (e.g., through a graphics processor
or accelerator), and to the high-speed expansion ports 1310, which
may accept various expansion cards (not shown). In the
implementations, the low-speed interface 1312 is coupled to the
storage device 1306 and the low-speed expansion port 1314. The
low-speed expansion port 1314, which may include various
communication ports (e.g., USB, Bluetooth.RTM., Ethernet, wireless
Ethernet) may be coupled to one or more input/output devices, such
as a keyboard, a pointing device, a scanner, or a networking device
such as a switch or router, e.g., through a network adapter.
[0168] The computing device 1300 may be implemented in a number of
different forms, as shown in the figure. For example, it may be
implemented as a standard server 1320, or multiple times in a group
of such servers. In addition, it may be implemented in a personal
computer such as a laptop computer 1322. It may also be implemented
as part of a rack server system 1324. Alternatively, components
from the computing device 1300 may be combined with other
components in a mobile device (not shown), such as a mobile
computing device 1350. Each of such devices may contain one or more
of the computing device 1300 and the mobile computing device 1350,
and an entire system may be made up of multiple computing devices
communicating with each other.
[0169] The mobile computing device 1350 may include a processor
1352, a memory 1364, an input/output device such as a display 1354,
a communication interface 1366, and a transceiver 1368, among other
components. The mobile computing device 1350 may also be provided
with a storage device, such as a micro-drive or other device, to
provide additional storage. Each of the processor 1352, the memory
1364, the display 1354, the communication interface 1366, and the
transceiver 1368, are interconnected using various buses, and
several of the components may be mounted on a common motherboard or
in other manners as appropriate.
[0170] The processor 1352 can execute instructions within the
mobile computing device 1350, including instructions stored in the
memory 1364. The processor 1352 may be implemented as a chipset of
chips that include separate and multiple analog and digital
processors. The processor 1352 may provide, for example, for
coordination of the other components of the mobile computing device
1350, such as control of user interfaces, applications run by the
mobile computing device 1350, and wireless communication by the
mobile computing device 1350.
[0171] The processor 1352 may communicate with a user through a
control interface 1358 and a display interface 1356 coupled to the
display 1354. The display 1354 may be, for example, a TFT
(Thin-Film-Transistor Liquid Crystal Display) display or an OLED
(Organic Light Emitting Diode) display, or other appropriate
display technology. The display interface 1356 may comprise
appropriate circuitry for driving the display 1354 to present
graphical and other information to a user. The control interface
1358 may receive commands from a user and convert them for
submission to the processor 1352. In addition, an external
interface 1362 may provide communication with the processor 1352,
so as to enable near area communication of the mobile computing
device 1350 with other devices. The external interface 1362 may
provide, for example, for wired communication in some
implementations, or for wireless communication in other
implementations, and multiple interfaces may also be used.
[0172] The memory 1364 stores information within the mobile
computing device 1350. The memory 1364 can be implemented as one or
more of a computer-readable medium or media, a volatile memory unit
or units, or a non-volatile memory unit or units. An expansion
memory 1374 may also be provided and connected to the mobile
computing device 1350 through an expansion interface 1372, which
may include, for example, a SIMM (Single In Line Memory Module)
card interface. The expansion memory 1374 may provide extra storage
space for the mobile computing device 1350, or may also store
applications or other information for the mobile computing device
1350. Specifically, the expansion memory 1374 may include
instructions to carry out or supplement the processes described
above, and may include secure information also. Thus, for example,
the expansion memory 1374 may be provide as a security module for
the mobile computing device 1350, and may be programmed with
instructions that permit secure use of the mobile computing device
1350. In addition, secure applications may be provided via the SIMM
cards, along with additional information, such as placing
identifying information on the SIMM card in a non-hackable
manner.
[0173] The memory may include, for example, flash memory and/or
NVRAM memory (non-volatile random access memory), as discussed
below. In some implementations, instructions are stored in an
information carrier. that the instructions, when executed by one or
more processing devices (for example, processor 1352), perform one
or more methods, such as those described above. The instructions
can also be stored by one or more storage devices, such as one or
more computer- or machine-readable mediums (for example, the memory
1364, the expansion memory 1374, or memory on the processor 1352).
In some implementations, the instructions can be received in a
propagated signal, for example, over the transceiver 1368 or the
external interface 1362.
[0174] The mobile computing device 1350 may communicate wirelessly
through the communication interface 1366, which may include digital
signal processing circuitry where necessary. The communication
interface 1366 may provide for communications under various modes
or protocols, such as GSM voice calls (Global System for Mobile
communications), SMS (Short Message Service), EMS (Enhanced
Messaging Service), or MMS messaging (Multimedia Messaging
Service), CDMA (code division multiple access), TDMA (time division
multiple access), PDC (Personal Digital Cellular), WCDMA (Wideband
Code Division Multiple Access), CDMA2000, or GPRS (General Packet
Radio Service), among others. Such communication may occur, for
example, through the transceiver 1368 using a radio-frequency. In
addition, short-range communication may occur, such as using a
Bluetooth.RTM., Wi-Fi.TM., or other such transceiver (not shown).
In addition, a GPS (Global Positioning System) receiver module 1370
may provide additional navigation- and location-related wireless
data to the mobile computing device 1350, which may be used as
appropriate by applications running on the mobile computing device
1350.
[0175] The mobile computing device 1350 may also communicate
audibly using an audio codec 1360, which may receive spoken
information from a user and convert it to usable digital
information. The audio codec 1360 may likewise generate audible
sound for a user, such as through a speaker, e.g., in a handset of
the mobile computing device 1350. Such sound may include sound from
voice telephone calls, may include recorded sound (e.g., voice
messages, music files, etc.) and may also include sound generated
by applications operating on the mobile computing device 1350.
[0176] The mobile computing device 1350 may be implemented in a
number of different forms, as shown in the figure. For example, it
may be implemented as a cellular telephone 1380. It may also be
implemented as part of a smart-phone 1382, personal digital
assistant, or other similar mobile device.
[0177] Various implementations of the systems and techniques
described here can be realized in digital electronic circuitry,
integrated circuitry, specially designed ASICs (application
specific integrated circuits), computer hardware, firmware,
software, and/or combinations thereof. These various
implementations can include implementations in one or more computer
programs that are executable and/or interpretable on a programmable
system including at least one programmable processor, which may be
special or general purpose, coupled to receive data and
instructions from, and to transmit data and instructions to, a
storage system, at least one input device, and at least one output
device.
[0178] These computer programs (also known as programs, software,
software applications or code) include machine instructions for a
programmable processor, and can be implemented in a high-level
procedural and/or object-oriented programming language, and/or in
assembly/machine language. As used herein, the terms
machine-readable medium and computer-readable medium refer to any
computer program product, apparatus and/or device (e.g., magnetic
discs, optical disks, memory, Programmable Logic Devices (PLDs))
used to provide machine instructions and/or data to a programmable
processor, including a machine-readable medium that receives
machine instructions as a machine-readable signal. The term
machine-readable signal refers to any signal used to provide
machine instructions and/or data to a programmable processor.
[0179] To provide for interaction with a user, the systems and
techniques described here can be implemented on a computer having a
display device (e.g., a CRT (cathode ray tube) or LCD (liquid
crystal display) monitor) for displaying information to the user
and a keyboard and a pointing device (e.g., a mouse or a trackball)
by which the user can provide input to the computer. Other kinds of
devices can be used to provide for interaction with a user as well;
for example, feedback provided to the user can be any form of
sensory feedback (e.g., visual feedback, auditory feedback, or
tactile feedback); and input from the user can be received in any
form, including acoustic, speech, or tactile input.
[0180] The systems and techniques described here can be implemented
in a computing system that may include a back end component (e.g.,
as a data server), or that may include a middleware component
(e.g., an application server), or that may include a front end
component (e.g., a client computer having a graphical user
interface or a Web browser through which a user can interact with
an implementations of the systems and techniques described here),
or any combination of such back end, middleware, or front end
components. The components of the system can be interconnected by
any form or medium of digital data communication (e.g., a
communication network). Examples of communication networks include
a local area network (LAN), a wide area network (WAN), and the
Internet.
[0181] The computing system can include clients and servers. A
client and server are generally remote from each other and
typically interact through a communication network. The
relationship of client and server arises by virtue of computer
programs running on the respective computers and having a
client-server relationship to each other.
[0182] In view of the structure, functions and apparatus of the
systems and methods described here, in some implementations, a
system and method for injecting state and routing information into
a communication exchange between a platform server and an end-point
device over a stateless persistent connection are provided. Having
described certain implementations of methods and apparatus for
supporting injection of the state and routing information into the
communication exchange, it will now become apparent to one of skill
in the art that other implementations incorporating the concepts of
the disclosure may be used.
[0183] Moreover, in view of the structure, functions and apparatus
of the systems and methods described here, in some implementations,
a system and method for communication over a set of persistent
connections between two network nodes and an intermediary node are
provided. Having described certain implementations of methods and
apparatus for supporting communication over the persistent
connection, it will now become apparent to one of skill in the art
that other implementations incorporating the concepts of the
disclosure may be used.
[0184] Moreover, in view of the structure, functions and apparatus
of the systems and methods described here, in some implementations,
a system and method for communication over a set of persistent
connections between two network nodes and an intermediary node are
provided. Having described certain implementations of methods and
apparatus for supporting communication over the persistent
connection, it will now become apparent to one of skill in the art
that other implementations incorporating the concepts of the
disclosure may be used.
[0185] Therefore, the disclosure should not be limited to certain
implementations, but rather should be limited only by the spirit
and scope of the following claims.
* * * * *