Content deleted Content added
→Real-time systems: rm unused acro. fix redlink. |
m Clean up spacing around commas and other punctuation fixes, replaced: ,P → , P |
||
Line 18:
==Reliability properties==
A reliable service is one that notifies the user if delivery fails, while an ''unreliable'' one does not notify the user if delivery fails.{{
In the context of distributed protocols, reliability properties specify the guarantees that the protocol provides with respect to the delivery of messages to the intended recipient(s).
Line 34:
Reliable messaging is the concept of [[message passing]] 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.
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.
==Implementations==
Line 43:
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}}
[[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:
| |||