- What is an X.25 Network?
- X.25 Layers compared with TCP/IP
- X.25 Addresses (NUAs)
- Virtual Circuits
- X.25 Logical Channels - what are they?
- SVCs
- PVCs
- Data Transfer and Packetization - Differences from TCP
- X.25 Network Reliability
- IP over X.25
- XOT (X.25 over TCP/IP)
- Point to Point X.25
- DCE and DTE - what are they?
- The Physical Link
- LAPB - the data link layer
- LAPB - types of frame
- LAPB - frame structure
- X.25 Packet Layer - the network layer
- X.25 Packet Layer - packet types
- X.25 Facilities
- X.25 Resets
- Using the FarSync Sockets API to interface to X.25
X.25 Permanent Virtual Circuits (PVC)
PVCs may at first glance appear to be simpler to handle than SVCs, as there is no call set-up and clearing with which to deal.
However, working out the state of remote DTE is not so simple - for example, it be may be powered off, or there may not be an application attached to the PVC. This therefore leads to a number of complications, so it is the opinion of the author that SVCs should be used instead of PVCs whenever there is a choice.
Having said that, PVCs are suitable:
- when a higher-layer protocol is used on top of the PVC to determine explicitly whether the remote application is responding;
- for the same sort of applications as used with UDP.
For example, market-feed applications are common on PVCs - indeed, some networks support a PVC broadcast facility, such that data packets transmitted on a PVC are then sent out by the network to a number of different remote DTEs.
The Call set-up and Clearing packets are not used on PVCs - the PVC starts in the data transfer state. Because the PVC will probably have been used previously, when attaching to a PVC an application should cause the PVC to be Reset.
Using the FarSync X.25 Sockets API with PVCs
14-Sep-2016