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.

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.

Iotellect Iotellect Server 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 Iotellect 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 Iotellect Server using outbound connections. Both sides meet 'at' the Iotellect Server and can thereby communicate through it.

Each Device Server that needs to use the Link Service has to be registered on the Iotellect Server first, i.e. have a Device Server Account. The Iotellect Server recognizes Device Servers through a combination of data in the following settings: Device Name (DN), Owner Name (ON) and Password (PW). Each registered Device Server is assigned a unique port number during the registration. This is a port on the Iotellect Server to which any client wishing to communicate with this particular Device Server should connect.

The Device Server logs on to the Iotellect Server using its device name, owner name and password. Typically, the DS is preset to do so immediately when it boots (starts up). The Iotellect Server has a single port for Device Server logins -- 6450 by default. Because Device Servers are uniquely identified by their device name, owner name and password, a single login port for all Device Servers is sufficient.

A "client" host who wishes to communicate with a particular Device Server establishes a connection to the Iotellect Server, to the specific port that was assigned to this Device Server during registration. The link is thus created and both sides may exchange data.

A client host does not need any special login procedure to create this connection to the Device Server via the Iotellect Server. Instead of connecting to the IP address and port of the DS directly, it connects to the IP address of the Iotellect Server and to the port associated with a particular DS -- the difference is in parameter values only.

Link Service feature is implemented through a Transparent Data Routing (Link Service) Device Driver. See this article for further details.

Was this page helpful?