|
One protocol that implements reliable messaging 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>
The [[Asynchronous Transfer Mode|ATM]] Service-Specific Coordination Function provides 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 does not receive an ACK frame within a predetermined period of time.
==Real-time systems==
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 a specified minimum reliability for the delivery of the critical data be met. Therefore, in these cases, it is only the delivery that matters; notification of the failure to deliver does ameliorate the failure. In [[hard real-time system]]s, all data must be delivered by the deadline or it is considered a system failure. In [[firm real-time system]]s, 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 addressing real-time requirements for reliable delivery and timeliness:
|
