Device Server Management
AggreGate provides several services for managing Tibbo Device Servers (both fixed-firmware and programmable) located in private networks.
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 which gave rise to several technologies allowing you to use available IP addresses more economically. Some examples of these technologies include:
These technologies allow 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 has 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 which 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 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, only this single host would be able to communicate with your Device Servers since 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.
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 and it is tailor-made for Tibbo Device Servers! Your Device Servers in the field connect to the Link Service (make outbound connections). Hosts wishing to communicate with Device Servers also connect to the AggreGate Server by 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 is not critical for systems which 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 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 DNS Service comes in. With DNS 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 directly established 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 communication 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 the 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 and 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 the AggreGate Server. It works like this:
The following license types are available for order: