Content deleted Content added
Removing merge template after merging (easy-merge) |
review: American English. section organization. |
||
Line 1:
{{Use American English}}
In [[computer networking]], a '''reliable''' protocol is a protocol
Reliable protocols typically incur more overhead than unreliable protocols, and as a result, function more slowly and with less scalability. This often is not an issue for [[unicast]] protocols, but it may become a problem for [[reliable multicast]] protocols.
Line 9 ⟶ 10:
==History==
After the [[NPL network]] pioneered [[packet switching]],<ref name="J. Gillies, R. Cailliau">{{cite book|url=https://books.google.co.uk/books?id=pIH-JijUNS0C&lpg=PA25&ots=MKZj0F7pJN&pg=PA25#v=onepage&q&f=false|title=How the Web was Born: The Story of the World Wide Web| first1=J. | last1=Gillies | first2=R. | last2=Cailliau | date=2000 | publisher=[[Oxford University Press]] | ISBN=0192862073 | pages=23-25 }}</ref> the [[ARPANET]] provided a reliable packet delivery procedure to its connected hosts via its [[BBN Report 1822|1822 interface]]. A host computer simply arranged the data in the correct packet format, inserted the address of the destination host computer, and sent the message across the interface to its connected [[Interface Message Processor]] (IMP). Once the message was delivered to the destination host, an
Meanwhile, the developers of [[CYCLADES]] and of [[ALOHAnet]] demonstrated that it was possible to build an effective computer network without providing reliable packet transmission. This lesson was later embraced by the designers of [[Ethernet]].
Line 30 ⟶ 31:
One of the most complex strong reliability properties is [[virtual synchrony]].
Strong reliability properties are offered by [[group communication system]]s (GCSs) such as [[IS-IS]], [[Appia framework]], [[Spread (group communication system)|Spread]], [[JGroups]] or [[QuickSilver Scalable Multicast]]. The [[QuickSilver Properties Framework]] is a flexible platform that allows strong reliability properties to be expressed in a purely declarative manner, using a simple rule-based language, and automatically translated into a hierarchical protocol.<!--[[User:Kvng/RTH]]-->▼
Reliable delivery can be contrasted with [[best-effort delivery]], where there is no guarantee that messages will be delivered quickly, in order, or at all.
▲'''Reliable messaging''' is the concept of communicating [[message passing|messages]] across an unreliable infrastructure whilst being able to make certain guarantees about the successful transmission of the messages.<ref>[http://www.w3.org/2001/03/WSWS-popa/paper40 W3C paper on reliable messaging]</ref> For example, that if the message is delivered, it is delivered at most once, or that all messages successfully delivered arrive in a particular order.
==Implementations==
One [[protocol (computing)|protocol]] that implements this concept is [[WS-ReliableMessaging]], which handles reliable delivery of [[SOAP]] messages.<ref>[http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-rm/ws-reliablemessaging200502.pdf WS-ReliableMessaging specification (PDF)]</ref>▼
A reliable delivery protocol can be built on an unreliable protocol. An extremely common example is the layering of [[Transmission Control Protocol]] on the [[Internet Protocol]], a combination known as [[TCP/IP]].
▲Strong reliability properties are offered by [[group communication system]]s (GCSs) such as [[IS-IS]], [[Appia framework]], [[Spread (group communication system)|Spread]], [[JGroups]] or [[QuickSilver Scalable Multicast]]. The [[QuickSilver Properties Framework]] is a flexible platform that allows strong reliability properties to be expressed in a purely declarative manner, using a simple rule-based language, and automatically translated into a hierarchical protocol.
▲Reliable delivery can be contrasted with [[best-effort delivery]], where there is no guarantee that messages will be delivered quickly, in order, or at all. A reliable delivery protocol can be built on an unreliable protocol. An extremely common example is the layering of [[Transmission Control Protocol]] on the [[Internet Protocol]], a combination known as [[TCP/IP]].
▲One [[protocol (computing)|protocol]] that implements
In the context of the [[Asynchronous Transfer Mode|ATM]] Service-Specific Coordination Function, for example for transparent assured delivery with [[ATM Adaptation Layer 5|AAL5]].<ref>Young-ki Hwang, et al., ''Service Specific Coordination Function for Transparent Assured Delivery with AAL5 (SSCF-TADAS)'', Military Communications Conference Proceedings, 1999. MILCOM 1999, vol.2, pages 878–882. {{doi|10.1109/MILCOM.1999.821329}} </ref><ref name="ATMF-INTRO" >ATM Forum, The User Network Interface (UNI), v. 3.1, {{ISBN|0-13-393828-X}}, Prentice Hall PTR, 1995.</ref><ref name ="AAL-5 spec">ITU-T, ''B-ISDN ATM Adaptation Layer specification: Type 5 AAL'', Recommendation I.363.5, International Telecommunication Union, 1998.</ref>
[[IEEE 802.11]] attempts to provide reliable service for all traffic. The sending station will resend a frame if the sending station doesn't receive an ACK frame within a predetermined period of time.
==
There is, however, a problem with the definition of reliability as "delivery or notification of failure" in [[real-time computing]]. In such systems, failure to deliver the real-time data will adversely affect the performance of the systems, and some systems, e.g. [[safety-critical]], [[Safety-involved systems|safety-involved]], and some secure [[mission-critical]] systems, must be [[formal methods|proved]] to perform at some specified minimum level. This, in turn, requires that there be a specified minimum reliability for the delivery of the critical data. Hence, it is only the delivery that matters, and notifying the sender does not negate or ameliorate this failure of the real-time system's [[transport layer]] to deliver.
In [[Real-time computing#Criteria for real-time computing|hard and firm real-time systems]] the data has to be delivered within a deadline, i.e. data that is delivered late is valueless. In hard real-time systems, all data must be delivered within its deadline or it is considered a system failure. In firm real-time systems, late data is still valueless but the system can tolerate some amount of late or missing data.<ref name = "Schneider et al 2001">S., Schneider, G.,Pardo-Castellote, M., Hamilton. “Can Ethernet Be Real Time?”, Real-Time Innovations, Inc., 2001</ref><ref name = "Rubenstein et al 1998">Dan Rubenstein, Jim Kurose, Don Towsley, ”Real-Time Reliable Multicast Using Proactive Forward Error Correction”, NOSSDAV ’98</ref>
There are a number of protocols that are capable of meeting real-time requirements for reliable delivery and timeliness, at least for firm real-time systems (due to the inevitable and unavoidable losses from, e.g., the physical layer [[bit error rate]]s):
Line 61 ⟶ 63:
TTEthernet provides the lowest possible latency in transferring data across such a network by using time-___domain control methods – each time triggered transfer is scheduled at a specific time, so that contention for shared resources is entirely controlled and thus the possibility of congestion is eliminated. The switches in the network enforce this timing to provide tolerance of faults in, and malicious actions on the part of, the other connected equipment. However, "synchronized local clocks are the fundamental prerequisite for time-triggered communication".<ref>Wilfried Steiner and Bruno Dutertre, [http://www.csl.sri.com/users/bruno/publis/fmics2010.pdf ''SMT-Based Formal Verification of a ''TTEthernet'' Synchronization Function''], S. Kowalewski and M. Roveri (Eds.), FMICS 2010, LNCS 6371, pp. 148–163, 2010.</ref> This is because the sources of critical data will have to have the same view of time as the switch, in order that they can transmit at the correct time and the switch will see this as correct. This also requires that the sequence with which a critical transfer is scheduled has to be predictable to both source and switch. This, in turn, will limit the transmission schedule to a highly deterministic one, e.g. the [[cyclic executive]].
However, low latency in transferring data over the bus or network does not necessarily translate into low transport delays between the application processes that source and sink this data. This is especially true where the transfers over the bus or network are cyclically scheduled (as is commonly the case with MIL-STD-1553B and STANAG 3910, and necessarily so with AFDX and TTEthernet) but the application processes are [[wikt:asynchronous|asynchronous]], e.g. [[Preemption (computing)|pre-emptively scheduled]], or only [[Plesiochronous system|plesiosynchronous]] with this schedule. In
With both AFDX and TTEthernet, there are additional functions required of the interfaces to the network for the transmission of critical data, etc., that make it difficult to use standard Ethernet interfaces, e.g. AFDX's Bandwidth Allocation Gap control, and TTEthernet's requirement for very close synchronization of the sources of time-triggered data. Other methods for control of the traffic in the network that would allow the use of such standard IEEE 802.3 network interfaces is a subject of current research.<ref name="Charlton et al 2013">D. W. Charlton, et al., "AN AVIONIC GIGABIT ETHERNET NETWORK", Avionics, Fiber-Optics and Photonics Conference (AVFOP), 2013 IEEE, 2013, pages 17–18. {{doi|10.1109/AVFOP.2013.6661601}} </ref>
| |||