AggreGate Device Server Management 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 Overview 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:
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.
- 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.
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 the necessary number of static IP addresses, there is still one more challenge: you actually have to 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 Overview The downside of the Link Server is that it is slower than a 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 down the device — 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 always can 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 configured appropriately. 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 an IP address from the 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 are transferred through the server.
HTTP Proxy Service Overview 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 static 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.
AggreGate Device Server Management Solution Resources
Choose Number of Device Servers The price displayed above is for up to 25 device servers. If you require more device servers, use the option selector below. The price shown by each option is the price increase over the 25-server version. Every version includes the AggreGate core, Link Service extension, Dynamic DNS extension, and HTTP Proxy extension.