![]() | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
![]() | The contents of the Reliable messaging page were merged into Reliability (computer networking) on 29 October 2019. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
For example, the TCP/IP protocol is connection-oriented, with the virtual circuit ID consisting of source and destination IP addresses and port numbers.
The virtual circuit article says [TCP] is not an example of virtual circuit application, although it is connection-oriented.
So what is correct? --Abdull 18:25, 8 May 2007 (UTC)[reply]
Addded recent entry to reliable multicast protocol TODO: cover any other arrivals Hulkeypoo (talk) 09:28, 30 May 2008 (UTC)[reply]
I am coming to the conclusion that I have a problem with the way the term “reliable delivery” is currently being used. While not (any longer) explicitly used in this article, it is used widely elsewhere, and has come to have a meaning that is, at best, misleading. An example of this use is in the lead section of the article on the Transmission control protocol (TCP). This states “TCP provides reliable, ordered and error-checked delivery…”. And, while not explicitly stated in this reliability article, this idea of “reliable delivery” on the part of such protocols as TCP is, at least, tacitly supported.
My problem stems from my research into the niche use of packet switched networks in firm real-time systems. These systems require that at least some of the data (that which is critical to their operation) be delivered with a low probability of loss. Basically the probability of the loss of consecutive instances of a specific, critical data transfer has to be down at the level required for the level of criticality of the data, e.g. not more often than once in a million hours of operation for flight safety-critical data. This is complicated by the fact that these data must be delivered with a maximum latency, i.e. within a deadline, as data delivered after its deadline is useless and thus equivalent to a failed delivery. This deadline requirement then makes it difficult to use retries to recover from, e.g., bit errors induced in the physical layers, but that’s bye the bye.
The problem itself is that we call this “reliable delivery”, i.e. we rely on the data being delivered. Whereas, what seems to be being meant by “reliable delivery” in the IP context is that the data is delivered or the sender is notified otherwise. I accept that this represents a “reliable service”, in that there are only two possible outcomes. However, I don’t accept that you can legitimately call this “reliable delivery” when one of those outcomes is that you are notified that it has not been delivered. The only way that I could accept this as “reliable delivery” would be if there were a defined limit on the ratio between the two results, which is only the same as giving a probability for delivery (which can be relied on). But as loss rates with, e.g., TCP are entirely indeterminate, depending as they do on the actions of other users connected to the same network segments, there is no obvious a limit on the ratio that can be relied on and thus no way delivery itself, as one of the possible outcomes, can legitimately be called reliable : all that such reactive protocols can do, at best, is to maximize the likelihood of delivery for any given network condition, i.e. enhance the probability of delivery ; they do not offer any specific value for this probability, and if the network is sufficiently overloaded (e.g. with traffic claiming the highest priority), the probability of delivery can always approach zero.
So, I’m wondering if there should at least be a section in this article to address this issue, i.e. that the use in IP circles of “reliable delivery” is less than strictly accurate, and maybe some reference to the real-time data transport requirement for the reliability with which the data is actually required to be delivered. Some existing protocols that can legitimately be described as providing “reliable delivery” are MIL-STD-1553B and STANAG 3910 for buses, and Time Triggered Ethernet and AFDX for PSNs – though it is perhaps less than clear how you actually prove reliable delivery with AFDX. However, since I’m only really comfortable with the latter aspect, what “reliable delivery” means in the real-time context, I thought I’d canvas opinion here, before being quite so bold.
Graham.Fountain | Talk 10:13, 12 August 2014 (UTC)[reply]
I think the first paragraph is now circular, as it defines reliability as assurance and then says they are synonyms. It is, however, true that it was vague before, but I don't think it's much less vague now.
I think the basic problem stems from the fact that most people think that reliable protocols like TCP guarantee delivery. This has been made very clear to me in the course of the work I do with real-time data transport. Whereas, as we know, what they actually do is improve the probability of delivery – a single re-try roughly squares an already small probability of loss – and report the success or failure in delivering the data. In a sense, it’s the difference between “reliable delivery” and “reliable transport”: what you get sold is the first; what you actually find in the box when you get it home, if you bother to look, is the second.
The problem, for me, that it is very easy to read "provides assurance of the delivery of data" as meaning that it makes it certain that data will be delivered, i.e. what the Oxford dictionary gives as the second meaning of assure: "Make (something) certain to happen". Whereas, what it really should say is more clearly related to the first meaning of assure: "Tell someone something positively to dispel any doubts." If I understand this correctly, the “make certain” use is as a simple transitive verb and the “tell someone something positively” is in a dative use, with both a direct and indirect object – the “someone” and the “something”. However, while I can see that there are arguably two objects in “delivery of data”, I’m far from certain it’s obvious when it’s inflected like that.
So, I think that issue of assurance as “notification of delivery status” needs to be stated positively, rather than by double negative, as it currently is – “an unreliable protocol… does not provide notifications to the sender as to the delivery”.
Per WP:SDLENGTH, the short description of this article should be shortened immensely, ideally to around 40 characters. I've temporarily shortened it to "Ability of a computer network protocol" from "Ability of a computer network protocol to notify the sender of whether delivery of data was successful".
@Kvng notifying you of this before you revert my edit ~ Eejit43 (talk) 04:10, 29 December 2022 (UTC)[reply]