X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=doc%2Fhtml%2Ftep113.html;h=0e8b6d3666798604a6f9069ae7b5eb0f53b1d937;hb=f12a8a9432dda3ce3ba7ffef4276f2ea9c4437f8;hp=7f502393fb108de40b26afc143df3c4660406c59;hpb=2c0e71d50b57d3194611948f14645e5df2a6bc43;p=tinyos-2.x.git diff --git a/doc/html/tep113.html b/doc/html/tep113.html index 7f502393..0e8b6d36 100644 --- a/doc/html/tep113.html +++ b/doc/html/tep113.html @@ -298,9 +298,9 @@ ul.auto-toc {
Only the PC-to-mote communication path supports acknowledgements. +SerialP does not request acknowledgements from the PC for two reasons. +First, acks are not perfect reliable: they are used on the +PC-to-mote path to raise reliability to a usable level. In the case of +the PC-to-mote path, the UART receive buffer is typically a single +byte, so a high interrupt load can easily lose (and sometimes does) a +byte. This is in contrast to the PC receive buffer, which is much +larger and does not have to deal with overflow. Second, adding support +for acks would increase the code size and complexity of the serial +stack. As code space is often at a premium, this would add little +needed functionality at significant cost. Of course, any application +that requires perfect reliability may layer its own scheme on top of +the serial protocol.
+The acknowledgement protocol is stop-and-wait to minimize buffering on +the mote side. This is considered more important on memory constrained +devices than increased throughput in the PC-to-mote direction, which +most applications only use for occasional control transmissions.