Jump to content

Talk:Acknowledgement (data networks)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Talk:Nak)

So what protocols *do* acknowledge every byte transmitted?

[edit]

The article currently says

Many computer network protocols do not immediately acknowledge every byte transmitted. Some of them wait until the end of each network packet, and then acknowledge each packet.

So does "immediately acknowledge every byte transmitted" mean that, for every byte transmitted, an acknowledgement is sent? If so, what protocols do that?

TCP doesn't have "packets" with significance to the user of the TCP service, so acknowledgments do acknowledge bytes, but it doesn't necessarily acknowledge each byte as transmitted, because a single TCP segment with data will very often have more than one byte, and so the TCP receiver will not see each byte separately. In other protocols, the service offered is in units of PDUs, not bytes, so there are no bytes to acknowledge. TCP, and those other protocols, are transmitted over networks where the adapter doesn't notify the recipient as each byte is received, so they can't immediately acknowledge every byte transmitted; that could only happen in the adapter at the physical layer. Guy Harris (talk) 20:17, 7 August 2017 (UTC)[reply]

This unsourced bit was recently added by DavidCary. Rather than delete it I cleaned it up a bit and hoped that others would boldly improve it further. I guess hardware-based protocols have the ability to individually acknowledge every byte. ~Kvng (talk) 15:19, 10 August 2017 (UTC)[reply]
The I2C protocol normally sends a single acknowledge bit after each and every byte transmitted.
The CAN bus also normally sends a single acknowledge bit, but at the end of each and every frame of data.
Thank you for the improvements, Kvng and Guy Harris.
I feel there used to be a wide division between a "data network" where both the data and the acknowledgements alternately travel over the same copper wire (such as TCP over CAT5 cable, and multimaster I2C protocol over the same CAT5 cable[1][2]), vs. a "computer system bus" with a separate wire dedicated to the acknowledge signal and nothing else.
I realize that there might be better division(s) that would be more useful to today's readers.

References

Recent edit summaries to this article mention "hardware protocol", "bus protocol", "network protocol" as if they are 2 (or 3?) different things, which I feel are important concepts that *should* be defined and discussed and compared and contrasted somewhere on Wikipedia. Which Wikipedia article should (or perhaps already does?) compare these things? --DavidCary (talk) 17:52, 15 August 2017 (UTC)[reply]
That would be nice. You can start by having a look at Communications protocol. That is a comprehensive mess and still lacks such a discussion. Maybe also Bus (computing). ~Kvng (talk) 15:21, 16 August 2017 (UTC)[reply]

"Acknowledgment" or "acknowledgement"?

[edit]

A quick look at https://www.lexico.com suggests that "acknowledgment" is the primary spelling of the word in question in US English, with "acknowledgement" as an alternate spelling, and that "acknowledgement" is the primary spelling of the word in question in UK English. Neither entry speaks of the word in the context of telecommunications.

The article was recently edited to change one instance of "acknowledgment" to "acknowledgement", but others remain.

The article has the {{Use British English}} template. In the context of telecommunications, is "acknowledgement" the proper British English spelling? If so, all of the instances should presumably be changed, with "acknowledgment" listed at the top as one of two spellings, after "acknowledgement", and perhaps with indications of the language variants for which they're appropriate. Guy Harris (talk) 08:00, 9 May 2022 (UTC)[reply]

This is a simple WP:ENGVAR issue. Since the article is titled and tagged for British English, we should be using "acknowledgement" throughout. I have made the corrections. ~Kvng (talk) 13:38, 16 May 2022 (UTC)[reply]