MicroController Pros Home Page My Account  Cart Contents  Checkout  
  Store » Tibbo » Tibbo Software » AGG-DS My Account  |  Cart Contents  |  Checkout   
Quick Find
Enter keywords to find the product you are looking for in the Quick Find field above

or use
Advanced Search
Accessory Boards->
ADI Blackfin
Atmel AVR->
Cypress PSoC
Microchip PIC->
Silicon Labs
ST Microelectronics->
Texas Instruments->
  BASIC Programmable
  RS232/422/485 to Ethernet
  Tibbo Project System->
  Tibbo Software
Embedded Ethernet->
Embedded Software->
I/O Modules->
Parts & Components->
Pick & Place Tools
Programmable Logic (PLD)
Prototype PCBs->
ROM/Flash Emulators
Test & Measurement->
Tutorial Software
Universal Programmers->
Intro to Embedded Tools
Embedded News Digest
Useful Resources
Shipping & Returns
Warranty & Liability
Privacy Notice
Conditions of Use
Contact Us
AggreGate Device Server Management Solution US$400.00

AggreGate Device Server Management Solution

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:

  • 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 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.

Available Options:

This product was added to our catalog on Tuesday 03 July, 2012.


Shopping Cart more
0 items
What's New? more
Flowcode 7 for PIC, AVR, Arduino, ARM - Academic Single User
Flowcode 7 for PIC, AVR, Arduino, ARM - Academic Single User
Specials more
Male 5-pin, 3.81mm Terminal Block, right angle, PCB mount
Male 5-pin, 3.81mm Terminal Block, right angle, PCB mount
Tell A Friend

Tell someone you know about this product.
Notifications more
NotificationsNotify me of updates to AggreGate Device Server Management Solution
Reviews more
Write ReviewWrite a review on this product!
  Thursday 21 February, 2019   List of all our Products

Copyright © 2003-2017 MicroController Pros LLC
Powered by osCommerce