XNet allows X.25 network users to seamlessly switch to an Internet/intranet solution, without changing their X.25 interfaces at the central or branch offices.
Telecom companies, if they have not already done so, plan to phase out their X.25 public or private data networks. The lack of personnel to maintain these legacy networks and equipment results in ever increasing costs.
In addition to an X.25 network, most telecom customers already use the Internet and/or an intranet for their interoffice communication. Eliminating the cumbersome and expensive X.25 network and replacing it with the TCP/IP WAN makes sense.
At the customer site, it is more often the host (mainframe) that cannot easily be changed. The application for these legacy systems is still working fine. It normally uses a proprietary interface into a third party X.25 protocol stack and a synchronous adapter. It is likely that none of the parties that developed the application, the X.25 protocol and the synchronous adapter are still in business. The documentation and source code is unlikely to be available. The source code is often written in COBOL or PL/1 or is in a questionable state. Modifying the application is, therefore, extremely difficult. The status quo seems to be the only option.
Many larger X.25 customers may be reluctant to delegate the
responsibility for their X.25 connections to a third party. They would prefer that the telecom company is still responsible. If required, we are willing to work with your local telecom. At Swisscom's PayPhone network, we used XNet, exchanging a private X.25 PSDN with an intranet. For the last 2 years, the XNet installation has worked without any problem.
XNet is a service module that exchanges X.25 for TCP/IP. It extracts X.25 user data (the payload) and forwards it via TCP/IP. XNet adds X.25 port access to the Internet/intranet, just as the X.25 PSDN did. Tymnet, one of the original PSDNs in the U.S., did not use X.25, but a proprietary protocol for their internal network, while Telenet did. Not all of the many X.25 options are relevant for TCP/IP. If relevant, they could be added.
When an X.25 Call Request is received on a logical channel, either a Call Connected is immediately sent and the call on the SVC is established, or the call is cleared. In case of PVCs, incoming X.25 data packets will establish the PVC. We recommend first exchanging Resets, to ensure that both PVCs are available.
Once the X.25 connection is in data transfer state, XNet establishes the TCP connection to an IP address and TCP port number indicated by an X.25 Address Map. The address can be that of either another XNet server or a program running on a PC or workstation written to the XNet API, which is listening on that port.