Stay-Linked Difference

The Technical Difference:

For the IP connection between the Stay-Linked Client and the Stay-Linked Server, the ‘Client2Host’ communications protocol is used. This protocol, designed from the ground up for the RF environment, utilizes UDP/IP to transmit data between the Stay-Linked thin-client software, residing on the wireless device, and the Stay-Linked server, on the Host computer. Because Stay-Linked uses UDP, it is able to avoid the IP traffic and connection issues that are inherent in the TCP protocol and exacerbated in a wireless environment.

The Client2Host protocol is quiet, only transmitting data across the network on the demand of the client. If the client device is inactive, then there will be no traffic generated on the network.

The Client2Host protocol implements a ‘Micro-Packet’ technology and ensures that UDP packets successfully arrive at the destination host in order. The ‘Micro-packet’ technology enables more reliable delivery of data by never transmitting packets greater than 512 bytes in length, thereby avoiding packet fragmentation and MTU issues. The ‘Micro-packet’ technology also enables Stay-Linked traffic to better utilize low-bandwidth or high-utilization network connections.

Because all of the session traffic between the Stay-Linked client and the Stay-Linked Server is encapsulated in the Client2Host protocol, Stay-Linked is able to avoid transmitting any TCP or TELNET protocols over the wireless network. In other words, there will be no Telnet clear-text traffic traveling across the network while running Stay-Linked.

On the mobile device, only Stay-Linked thin-client software is installed. This software has a minimal footprint on the device, so that device resources are preserved for other applications (including voice-enabled terminal emulation, using Stay-Linked VoiceWedge™).

Stay-Linked Server software is installed on the Host computer, next to both the Telnet/SSH server and Host-resident business applications.

The Stay-Linked thin-client software residing on the mobile device sends data entered on the device to the Server, which then communicates with the Host-resident Telnet or SSH sesssion to transmit the date to the Host-resident application. The resulting emulation screen change is then returned from the Host to the remote device.

In essence, wireless workers "remote control" business applications instead of having "fat apps" distributed throughout the enterprise. It just makes sense.

Real RF Solutions should be designed and built from the ground up—not cobbled-together from hastily-created parts in an attempt to mimic features introduced by Stay-Linked. Even numerous add-ons and patches to free bundled legacy emulators don’t provide the reliability and functionality flawlessly provided by Stay-Linked.

Before Stay-Linked was introduced in 2003, session persistence and session management features--such as monitor, remote control, share, and transfer—were not available. Since those features were introduced by Stay-Linked, the 90’s-era emulators have added bits and pieces to try to match the Stay-Linked solution. Proxy servers and gateways have been added, and device remote-control is being touted as session remote control. These cobbled-together offerings cause problems for resellers and customers alike, and they just don’t work as well as Stay-Linked in today’s wireless environment.

Cobbled-together components drive up costs and introduce complexity—not what you want from a terminal emulation solution.

Telnet remains on the host—using port filtering, no telnet is broadcast over the wireless network

Firewall-Friendly communications architecture
(Port restrictions and Static NAT Configuration for Servers. NAT friendly connections for Clients)

Native, proprietary, end-to-end, application layer encryption technology
(Dynamic-Symmetric 64-bit key, Stream-Cipher Symmetric Encryption Algorithm)

The User's Difference:

With Stay-Linked, the terminal emulation session resides on the host computer, next to the host-based application. Only a thin client is installed on the remote wireless device, which is used to communicate with the host-based Stay-Linked Server.

So if a worker needs to change a battery–even in the middle of a transaction—the host-resident session stays alive. When the worker reconnects, he's returned to the exact same screen and cursor location. Flawlessly.

With Stay-Linked, the terminal emulation session resides on the host computer, next to the host-based application. Only a thin client is installed on the remote wireless device, which is used to communicate with the host-based Stay-Linked Server.

The Stay-Linked Administrator console runs on any network-connected Windows computer. It looks at the same terminal emulation session that's being displayed on the remote device.

Sessions can be monitored, taken over, partnered, or even transferred to another remote device. All from the Help Desk.

Out of range? Dead battery? Device run over by a forklift? No problem (except for the guy who left the device in front of the forklift). The host-based session is still alive, and can be completed, shared, or even transferred to another device. Flawlessly.