ACK packets as expected. In the final stretch you'll do testing to determine transmission rates and timeout values, add BEACON frames and clock synchronization, deal with checksums, and shake out all of the remaining bugs.
ACKs, timeouts, and management of the collision window.) The
timing details diagram might also come in handy. All timing values should be based on the constants defined in the RF class (RF.h for you C++ fans), which also defines the maximum number of retransmission attempts.
Note that 802.11 broadcast messages (data packets sent to the broadcast address) are handled differently than those sent to a single, specific address: No ACK is expected in response to a broadcast message, so you can bypass the "waiting for an ACK" stages in your diagram after sending one.
ACK packet back to the sender whenever you receive a data packet addressed to your station. (Don't worry about checksums yet — assume all incoming packets are undamanged for now.) Do not send ACKs back if the incoming data packet used the broadcast address. Make sure you wait the required amount of time before transmitting the ACK.
When transmitting data frames, you must wait for the proper acknowledgement before proceeding to send the next frame. If an ACK doesn't arrive in a reasonable amount of time, retransmit your packet (with the retransmission bit set) according to the MAC rules. Move on to the next outgoing packet if no ACK arrives after making the specified maximum number of retransmission attempts. For now, you can make up a fixed timeout value based on the time required to transmit the default sample message used by WiFiClient. (Eventually we'll measure transmission times more precisely and work out a better scheme for timeout values.)
Note: When sending ACKs, you should not go through all of the media-access steps that you do when sending data. Just wait SIFS and then send. Other stations should all be waiting at least DIFS before they'd try to send, so unless someone is breaking the rules you should have the channel to yourself when it comes time to send an ACK. In the real world there's an even shorter interval (PIFS), so someone might actually beat you to the channel, but that can't happen in 802.11~ since SIFS is the shortest interval in our system and only one host should be trying to send an ACK at a time.
ACK packets should carry valid sequence numbers. The 802.11 specification says that sequence numbers always start at zero, and that you must maintain a "next sequence number" for each destination. ACKs should carry the sequence number of the packet they're acknowledging.
When receiving data packets, use the sequence numbers to ensure that you do not queue duplicate transmissions for delivery. Print a warning to the output stream if you detect a gap in the sequence numbers on incoming data packets from any given host, but accept and queue the data.