Titel:

Realible Asynchronous Transfer Protocol

Startseite
Artikelliste
english
  
ISBN: 3423050012   ISBN: 3423050012   ISBN: 3423050012   ISBN: 3423050012 
 
|<< Anfang     < Zurück     Index     Weiter >     Ende >>|
  Wir empfehlen:       
 

6.6. Outside Flow Control

There are many large computer systems which make use of flow control to regulate their input side of an RS-232 link. Flow control based upon two special characters such as <Ctrl-S> (ASCII DC3) and <Ctrl-Q> (ASCII DC1) is almost universally in use today. So it becomes important for the protocol to be able to either:

(1) Recognize and obey the flow control of the host computer(s), or

(2) Ignore the flow control but still guarantee reliable data reception.

It is the latter approach which this protocol takes. This decision was made because the number of differing flow control characters in use would make it difficult to obey them all.

There is a particular type of flow control with which this protocol will not operate. The ENQUIRE, ACKNOWLEDGE method of flow control requires that the receiver of an inquiry respond with an acknowledge before any more data will be sent to it. This type of flow control also usually prohibits unrestricted 8-bit data transmission because the inquiry character is forbidden as a data byte.

For the other class of flow control methods a proof is required that data may still be reliably transmitted and received if flow control is ignored. For the purposes of this discussion assume <Ctrl-S> is sent when the receiving end of the connection wishes the sender to stop transmitting. A <Ctrl-Q> is sent when the receiver wishes the sender to resume. The choice of these particular two characters is arbitrary. If the sender does not immediately cease transmission upon receipt of the <Ctrl-S>, characters may be discarded. Since this protocol chooses to ignore the flow control characters any part of a packet may be discarded.

More precisely stated consider X to be the receiver and Y to be the sender. The packet sent is represented by the string abc where a, b, and c are data segments of unspecified size. X may receive one of:

1. abc 2. ab 3. ac 4. bc

For case [1] the correct data is received and no special action need be taken.

For cases [2], [3], and [4] we have a situation identical to data dropped during transmission. This is handled by the same checksum, time-out and retransmission strategy already described.

Assume Y is not now in the act of receiving a packet, then Y sees the two characters <Ctrl-S> and <Ctrl-Q> appear as input in that order. Y is waiting for a message to appear and so expects to see a SYNCH pattern. If the two characters "<Ctrl-S><Ctrl-Q>" are not part of a SYNCH pattern then they will be immediately discarded. If Y is receiving a packet then the <Ctrl-S> and <Ctrl-Q> are seen to be added noise characters and would be detected by the checksum tests. The packet being received would require retransmission.

The question of which character to pick for the SYNCH pattern is slightly muddied by the above observation. To the author's knowledge <SOH> is rarely if ever picked for flow control. This is part of the motivation in using it as the SYNCH pattern.

How does one guarantee that any data will actually arrive successfully? The initial choice of maximum data counts during connection establishment is very important. Some knowledge of one's own operating system must be assumed. If it is known for example, that streams of data in excess of a certain length will often trigger flow control at the connection baud rate, then the maximum data count should be chosen sufficiently lower that flow control rarely will be employed. An intelligent choice of the maximum data count will guarantee that some packets will arrive without encountering flow control.

6.7. Packets that are too Large

Assume a packet arrives which passes its header checksum test but whose LENGTH is larger than the MDL of the receiver. In such a case the sender has violated the protocol or a packet has a data error in the LENGTH octet and has passed the header checksum test. The latter is unlikely so that we assume the former. The receiver will abort his connection. The sender must inform the user "Error: Connection aborted due to MDL error", and go to the CLOSED state.

When the MDL is exceeded the receiver will transmit a legal reset:

<SN=received AN><CTL=RST>

  
Bürgerliches Gesetzbuch BGB
von Helmut Köhler
Siehe auch:
Handelsgesetzbuch HGB: ohne Seehandelsrech...
Arbeitsgesetze
Grundgesetz GG: Menschenrechtskonvention, Europäischer Gerichtsh...
Strafgesetzbuch StGB
Aktiengesetz · GmbH-Gesetz: mit Umwandlungsgesetz, Wertpapiererw...
Zivilprozeßordnung. ZPO
 
   
 
     
|<< Anfang     < Zurück     Index     Weiter >     Ende >>| 

Zurück zur Themenseite:
ScientificPublication.com/Startseite/Informatik/Spezifikationen

Das Setzen von Verweisen (Links) auf diese Seite ist gestattet und bedarf keine vorherige Absprache.

Artikelliste:
Realible Asynchronous Transfer Protocol
   
  Startseite  |  english  |  Bookmark setzen  |  Webseite weiterempfehlen  |  Impressum