Home | History | Annotate | Download | only in libupload

Lines Matching full:ack

231          opened the output file, it shall acknowledge this block with an ACK
246 times until it receives an ACK character. (This is part of the
484 He did some clever programming to detect false ACK or EOT, but basically
671 The single character ACK/NAK responses generated by the receiving program
710 has not received a valid ACK for the current block. Failure to observe
759 ACK
761 ACK
763 ACK
765 ACK
774 ACK
776 ACK
778 ACK
780 ACK
782 ACK
959 it is ACK'ed if the write open is successful. If the file cannot be
1010 ACK
1013 ACK
1015 ACK
1017 ACK
1021 ACK
1024 ACK
1071 ACK
1074 ACK
1076 ACK
1078 ACK
1082 ACK
1085 ACK
1088 ACK
1092 ACK
1095 ACK
1104 ACK
1107 ACK
1109 ACK
1111 ACK
1130 ACK
1133 ACK
1174 bypasses the usual wait for an ACK to each transmitted block, sending
1179 particular file, and also expects an ACK on the EOT sent at the end of
1216 ACK
1274 <ack> 06H
1352 makes the transmission susceptible to false termination due to an <ack>
1376 indicates that the receivers <ack> got glitched, and the sender re-
1394 that looked like an <ack>. Abort the transmission, sending a <can>
1404 When the sender has no more data, it sends an <eot>, and awaits an <ack>,
1411 the two most common line hits - a garbaged block, and an <ack> reply
1420 <--- <ack>
1424 <--- <ack>
1426 (ack gets garbaged) <--- <ack>
1427 <soh> 03 FC -data- xx ---> <ack>
1429 <--- <anything except ack>
1431 <--- <ack>
1697 received before the first <nak> or <ack> the sending program should set
1700 <ack> is received. This will assist the receiving program in determining
1701 the correct mode when the <soh> is lost or garbled. After the first <ack>
1744 <--- <ack>
1748 <--- <ack>
1750 (ack gets garbaged) <--- <ack>
1754 <--- <ack>
1756 <--- <ack>
1795 <--- <ack>
1799 <--- <ack>
1801 (ack gets garbaged) <--- <ack>
1805 <--- <ack>
1807 <--- <ack>