Archive Index (1999-2012) | 2013-current at | About  

Device Profile: SyncServer synchronous-to-IP converter

Feb 24, 2003 — by LinuxDevices Staff — from the LinuxDevices Archive

SyncServer 1000 is a small modem-like Linux appliance made by The Software Group Ltd. (TSG) that offers easy integration of “legacy” Wide Area Networks (WANs) with IP networks. The device is intended to allow companies to transparently convert older communications transport protocols (such as X.25, Frame Relay, and SNA) to TCP/IP, giving legacy applications direct access to IP-based LANs, intranets, and… the Internet.

The SyncServer 1000 has two interface ports: one, which connects to a broadband (10/100-BaseT) network; and another, that connects directly to the legacy WAN (X.25, Frame Relay, SNA) interfaced equipment. (One SyncServer 1000 is required to implement each physical legacy-to-IP conversion.) The device includes an API for integration with host application programs, and can be configured and administered remotely using a web browser.

A block diagram illustrating the system connection can be seen here.

“Many legacy networks with X.25, Frame Relay and SNA are still used today [for applications that include] telephone switches, point of sale systems, ATMs, credit/debit terminals, train signalling systems, and field data collection devices to name just a few. These legacy networks are quite reliable and companies have invested a great deal in hardware and applications,” explained TSG president Derek Vair. “SyncServer was developed to allow these legacy networks to be economically integrated with IP, allowing legacy data to be converted and carried over IP networks. The result is a much simpler, easier to manage IP-based network that provides immediate cost savings.”

A pair of SyncServers can also be combined into a switching configuration that provides framed synchronous connectivity using shared IP networking facilities instead of synchronous leased lines. In the “SyncSwitch” configuration, the SyncServer provides connectivity for devices which use HDLC frames as their base connectivity, such as PPP, Frame Relay, X.25, or SDLC.

Currently SyncServer is designed to operate on a secured Intranet, behind a firewall or via a VPN. However, later this year TSG plans to will release a secured SyncServer with integrated IPSEC VPN that can be deployed anywhere on the InterNet, explained TSG chief technical officer Ragnar Paulson. “We are also working on more switching functionality in the SyncSwitch model, and anticipate releasing a product capable of level 3 (X.25 packet level) switching in the near future,” Paulson added.

What's in the box?

The SyncServer's embedded computer is based on a Motorola PowerQUICC 850 processor, running at a clock speed of either 50 MHz or 80 MHz, and equipped with 16MB of RAM and 8MB of nonvolatile Flash memory. The device has two external interfaces: a 10/100 Mbps Fast Ethernet (10BaseT, 100BaseT) port, for connection to TCP/IP-based networks; and a synchronous serial port which can be factory-configured for either V.35, X.21, RS-232, or RS-449, which connects to the synchronous serial ports of legacy devices.

The SyncServer's embedded operating system is based on Linux kernel 2.4.19. Initially, the device's embedded OS was going to be based on a Linux kernel from Timesys. But after a compatibility problem arose in using the Linux Streams (LiS) environment which is used by TSG for protocol processing, the development team decided to use a “standard” kernel downloaded from, instead, which they adapted to the SyncServer's requirements.

There is no actual (physical) display for system configuration or administration purposes. Instead, the device implements a built-in webserver (BoA) which, combined with extensive diagnostic and management programs, allows remote system management and troubleshooting via a web browser over TCP/IP networks. “Wanware Linux” encapsulates TSG's own synchronous protocol implementations, and a the open source BusyBox program provides a resource-efficient set of system utilities.

Among the challenges that faced the development team was a lack of adequate tools to support Flash memory management and maintance. “We needed to have this in order to achieve the objective of remotely providing software — actually, firmware — updates,” recalled Paulson. “We felt this was a key requirement, since these devices will be widely dispersed geographically; and having to use a serial or JTAG port to change the boot image is a non-starter.”

“Memory allocation is always a challenge in an embedded system,” Paulson added. “Even today, with a fully developed product that's gone through QA, I feel that we don't fully understand where all the memory goes — the Linux kernel appears to gobble up significant memory 'just in case,' which makes it unavailable to our protocol implementation for buffers, which are a key limitation in our case.”

“Selection, then development of a protocol for interacting between the client (customer application) and server (SyncServer device) was tricky, continued Paulson. “We started in the hope that we could use one of the established standards — RPC, for example, which is the basis for NFS. After analysis, we decided that RPC imposed too much synchronization on the application and protocol service mechanism, so we discarded it in favur of a home-grown solution which has evolved significantly during the development process.”

“Going forward, we will implement a standards-based object-oriented mechanism, such as the CORBA architecture,” Paulson said. “But for now, we've dealt with the problem of taking an existing API designed to handle links and devices connected to the machine and making that same API work in a remote client / server environment, as far as is possible, and with no impact on performance.”

Why embed Linux?

“Familiarity,” noted Paulson. “We were already writing Linux code at both the driver and application level. We are also familiar with traditional embedded operating systems — such as Wind River's VxWorks and pSOS — and didn't feel that they offered us value concomitant with the costs involved.”

“Because we maintain software products for a large number of OS environments, including NT, Unix, and Linux, a platform-specific IDE (Integrated Development Environment) is not of interest to us, since these IDEs do not address multiplatform development opportunities,” Paulson added.

Asked what sort of future he sees for Linux in the embedded market, Vair predicted “Growth, fast growth,” adding that this would come “in spite of the fact that as the user base and vendor base increase, Linux will find itself increasingly fragmented. An example of this is the plethora of so-called 'real-time Linux' systems, none of which are truly compatible at the kernel data structure and algorithm level.”

Availability and price

The SyncServer 1000, which provides a single synchronous serial port, was introduced in January 2003, and is sold for $1495 (USD) in single-unit quantities. Other models are offered which provide 2 through 16 synchronous serial ports.

This article was originally published on and has been donated to the open source community by QuinStreet Inc. Please visit for up-to-date news and articles about Linux and open source.

Comments are closed.