ru.nethack

 
 - RU.NETHACK -------------------------------------------------------------------
 From : Vyacheslav Levchenko                 2:4626/17.147  14 Apr 2001  12:56:32
 To : Tolik Pozdeev
 Subject : Re: X.25
 -------------------------------------------------------------------------------- 
 

 
 11 апpеля 2001 11:49, Tolik Pozdeev писал All:
 
 TP> Где можно почитать пpо сабж.
 
 все что нашел y себя :(
 *<ДДДДДДДДДДДДДДДД*  #*/пОкоЦанО  X.25.txt/*#  *ДДДДДДДДДДДДДДДД>*
 
  > X.25
  > The CCITT developed the X.25 standard to define a reliable, relatively
  > low cost means of routing data through a shared network. An extremely
  > important aspect of X.25 is that the information being transmitted has
  > been converted into packets.
  >
  > Packets can be thought of as small fragments of information.
  > Specifically, a block of information is broken into smaller parts (
  > packets) before being transmitted on the physical network. The packet
  > methodology provides faster and more reliable error detection and
  > correction; it also prevents a system with a huge volume of information
  > to ship from tying up the network.
  >
  > In addition to the raw information, each packet also contains
  > information specifying its origin, its destination, and a number
  > indicating the "piece" of the information to which it corresponds. This
  > enables each packet to be treated as an independent entity, so that
  > packets from many different systems can be intermixed on the network
  > without concern about the order in which they are transmitted or even
  > the order in which they arrive. Each packet might take the best
  > possible route available at the time it is ready for transport.
  >
  > The application end points of the information (that is, the terminal
  > user and the application program) rarely see the information in its
  > packetized form. As part of its interface with the network, the
  > computer system converts the information into packets, and then
  > subsequently reassembles the packets into the original information (see
  > Figure 7.10).
  >
  > FIG. 7.10 Conceptual Packetizing
  >
  > This packet approach to transmitting data is extremely pervasive in the
  > networking world. In addition to being used by X.25, this approach is
  > also used by most LANs and many other data communications protocols
  > (although they are usually referred to as frames, as discussed in the
  > LAN section of this chapter). Specific to X.25 networks, however, is
  > the concept of a packet switching network (PSN).
  >
  > A PSN is a WAN through which packets are sent. The precise route that
  > packets take from point A to point B is not fixed and is immaterial to
  > the equipment at point A or point B, which checks only to see whether
  > the packets arrive intact (again, order is not a major concern).
  >
  > Because they don't have prescribed data routes, PSNs are often shown as
  > clouds in many networking diagrams (see Figure 7.11). When depicted in
  > this manner, information goes into the cloud at some point and comes
  > out at another. What goes on within the cloud is not the concern of
  > mere humans.
  >
  > FIG. 7.11 Typical X.25 Representation
  >
  > The inside of the cloud, however, is composed of packet-switching nodes
  > (also called PSNs, just to make life confusing). The switching nodes
  > can take routes to other switching nodes, and thus can route or reroute
  > data as necessary. For example, if a switching node has a packet to
  > forward and the best possible switching node to receive it is busy, the
  > node holding the packet will reroute it to another node for subsequent
  > rerouting (see Figure 7.12).
  >
  > FIG. 7.12 Inside of the X.25 "Cloud"
  >
  > Packet-switching networks often are associated with public data
  > networks (PDNs), but this relationship is certainly casual. A PDN is
  > normally a telephone system (or telephone company in the U.S.) that
  > offers data services to the public. It does not have to use
  > packet-switching to move information from point to point. If a PDN does
  > offer the services of a packet-switching network, it might be referred
  > to as a packet-switching data network (PSDN) or even a packet-switching
  > public data network (PSPDN). Clearly, the abbreviations are almost
  > endless.
  >
  > Furthermore, implementation of packet-switching networks is not limited
  > to telephone companies. In fact, PSNs can be constructed of telephone
  > links, fiber optic links, microwave links, satellite links, and other
  > forms of communications. Many large corporations have used these
  > diverse communication techniques to construct their own private PSN.
  > Because, in the final analysis, a packet switching network is a
  > cost-effective WAN, organizations with widely dispersed equipment find
  > this approach most effective in terms of both cost and function.
  >
  > The traditional packet-switching cloud is shown in Figure 7.13.
  >
  > FIG. 7.13 X.25 Interfaces
  >
  > Moving outside of this cloud, the interfaces between the computer
  > equipment and the cloud generally fall into one of two types of
  > devices:
  >
  > PAD. The packet assembly/disassembly device is a piece of hardware that
  > interfaces between the network and computer equipment incapable of
  > sending or receiving packets. This function is defined in CCITT
  > standard X.3. The purpose of the PAD, then, is to handle the conversion
  > of the raw data into packets for transmission into the packet-switching
  > cloud and, conversely, handle the reassembly of information from
  > packets received from the cloud. PADs most often are used to interface
  > terminals into the packet- switching network, but they are also used to
  > interface computer systems that cannot handle packet transformations on
  > their own.
  >
  >
  > A communications controller running (normally) the LAP-B protocol.
  > Rather than use an external device, such as a PAD, most computers use
  > an internal interface to directly connect to the packet-switching
  > network. These interfaces and their corresponding software drivers
  > provide much of the same function provided by a PAD. The advantage to
  > putting these interfaces into a computer is that computer software can
  > directly access the link (whereas in the PAD the link was external and,
  > for the most part, invisible to the software). For example, an office
  > automation package can communicate with a counterpart package operating
  > on the other "side" of the cloud.
  > For terminal traffic over packet-switching networks, two additional
  > standards come into play. First, the CCITT X.28 standard defines the
  > interface between an asynchronous terminal and a PAD. Second, the CCITT
  > X.29 standard defines the control procedures for information exchanges
  > between a PAD and another PAD (or an integrated controller). Just as
  > X.25 has become synonymous with packet-switching networks, X.29 has
  > become synonymous with interfacing terminals over packet-switching
  > networks.
  >
 
 *<ДДДДДДДДДДДДДДДД*  #*/пОкоЦанО  X.25.txt/*#  *ДДДДДДДДДДДДДДДД>*
 
 ... *C вами был*  #*/Vyacheslav Levchenko/*#   #*/.......stopped/*#
  * Origin:    ;(  Hack aNd cRack  ;( (2:4626/17.147)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

Тема:    Автор:    Дата:    X.25   Tolik Pozdeev   11 Apr 2001 11:49:48   X.25   Liar   11 Apr 2001 20:46:34   X.25   Dmitry Makidonov   16 Apr 2001 21:54:41   Re: X.25   Vyacheslav Levchenko   14 Apr 2001 12:56:32