|
Solutions > Device Servers
Device Server Management
AggreGate provides several services for managing Tibbo Device Servers (both fixed-firmware and programmable) located in private networks.
- Link Service transparently routes data through the server between devices and computers located in private networks and hidden from each other by firewalls.
- Dynamic DNS Service helps to locate devices that have no static IP addresses.
- HTTP Proxy Service provides global access to the web pages that are stored on the web servers embedded into devices located in private networks.
Link Service
Under normal circumstances, on a WAN, communicating with another node (host)
on the network can be difficult due to the following factors:
Scarcity of Static IP Addresses
IP addresses on many networks (especially, the Internet) are now in short
supply. This gave rise to several technologies that allow you to use
available IP addresses more economically. Some examples of these technologies
include:
- Dynamic IP addresses, whereby IP addresses of the hosts change from time to time,
- NAT (Network Address Translation) whereby several hosts communicate with the outside world through a single "external" IP address on a gateway.
These technologies allow for each host to make outgoing connections (for
example, to visit a website). However, it may be difficult (or actually
impossible) to establish an incoming connection to such a host -- you either
don't know its current address (because it's dynamic), or it doesn't even have
an external address of its own.
The only standard solution to this problem is to assign a static IP address
to each host you need to connect to. These static IP addresses have to be
obtained first. For example, you might need to lease them from your ISP. A
single IP-address wouldn't cost much but when a given system is to have many
nodes you end up spending considerable amounts of money. Even when the WAN is
private and IP addresses are free, there are administration costs related to
allocation of static IP addresses.
Firewalls blocking inbound traffic
Even assuming one has obtained necessary number of static IP addresses,
there is still one more challenge: you have to actually connect to the Device
Server. This may mean passing through firewalls. Firewalls usually restrict
inbound traffic, so you will need to arrange opening ports, etc. This requires
more work and increases the chances for possible security breaches (the more
internal IP addresses or ports accessible from the outside, the greater the
risk).
One possible solution to this is to configure all of the Device Servers for
outbound connections, and have them connect to one specific network host.
This could save leasing multiple IP addresses, so you would just need a single
IP address for this host. Unfortunately, this also means that just this single
host would be able to communicate with your Device Servers, as it would be
configured as their destination. As you can see, this solution, too, is not an
ideal one.
So, what is the best way to interconnect Device Servers and their "client"
hosts, when they are on different network segments, located behind firewalls,
and have no static IP addresses? It is called Link Service.
Link Service
It is usually much easier for a network host to connect out than to accept
an incoming connection. Unfortunately, with a normal link, at least one side
must accept an incoming connection.
AggreGate provides a workaround for this problem by letting both
sides of the link to communicate through a "middle-man" (Link Service), to
which they both can establish outbound connections.
When you and your friend use ICQ or MSN, you both connect to a central
server. Neither of you typically has a static IP address, but the server has a
static IP -- and this is what lets the "magic" happen. Both parties make
outbound connections, so no firewalls have to be configured and neither side
needs a static IP.
The Link Service is a very similar solution, only it is tailor-made for
Tibbo Device Servers! Your Device Servers in the field connect to the Link
Service (make outbound connections). Hosts that wish to communicate with
Device Servers also connect to the AggreGate Server using outbound connections.
Both sides meet 'at' the AggreGate Server and can thereby communicate through it.
Dynamic DNS Service
The downside of the Link Server is that it is slower than direct connection,
because all the data must go through the AggreGate Server.
This isn't critical for systems that do not produce a lot of traffic per
each node. Still, there are times where you might want to create a direct
connection to a device (for the sake of speed), but the IP address of this
device changes from time to time (as is the case with most ADSL connections).
You need a way to track the device down -- a way to overcome this and
connect to one 'stable' address. You need to know that this address belongs to
the Device Server you want, and be able to rely on it.
This is where the dDNS Service comes in. With dDNS Service each of your
Device Servers gets a "host name", which looks something like
dev1.abccorp.dev.srv1.com (in this example the domain name of your
server is srv1.com). You can always connect to your device using this
hostname. This URL stays the same even when the IP address of the Device
Server changes.
Since the actual connection is established directly to the Device Server
you would have to be able to reach it -- i.e, if it has a firewall protecting
it, the firewall must be appropriately configured. Configuration would be more
complex than with the Link Service, but you would gain an increase in
communications speed.
In Dynamic DNS mode, Device Servers connect to the AggreGate Server on startup
only, after obtaining IP address from DHCP server. After their registration in
DNS they break connection with the AggreGate Server and act exactly as "normal"
Device Servers, having no relations with AggreGate Server and other parts of
AggreGate. In contrast to Link Service mode, no connection between Device
Server and AggreGate Server is maintained. No data is transferred through the server.
HTTP Proxy Service
Let's say you have hundreds of Device Servers with embedded web servers,
with each such Device Server providing access to a number of web pages. It is
very easy to access every embedded Web Server when all of them have real s
tatic IP addresses. However, in real life, most Device Servers are installed
in local networks protected by firewalls, and static IP addresses cost money.
In this case, there is no way to access these Device Servers directly. The
HTTP Proxy service solves this problem by providing a generic way to access
all embedded web servers through AggreGate Server. It works like this:
- A Device Server with an embedded web server connects to the AggreGate Server. Its account should be configured to use HTTP Proxy mode.
- Someone wants to see the web pages from this particular Device Server, so they start a web browser and surf to a URL such as http://aggregateserver.bigcompany.com/dev/admin/dev1/data.html.
- The HTTP request sent by a browser is received and processed by the AggreGate Server.
- AggreGate Server redirects the HTTP request to the admin.dev1 Device Server, to which it is currently connected.
- The Device Server processes the request and sends the data.html page to the AggreGate Server.
- AggreGate Server forwards this page to the browser.
Purchase Online
The following license types are available for instant online order:
|
