Hello Chris, I'm thinking about how I would implement piggybacking. Is it better to combine DL_ACK and DL_DATA in the header and somehow seperate them at the other end, or is it best to make a seperate FRAMEKIND, like DL_DATA_ACK, that signifies that data and an acknowledgement has been sent? This is kinda outside the scope of the lab, but if it's the latter, how would this work if I wanted to combine more than just acknowledgements and data? For example, if I had 4 different frame types that could all piggyback each other, I would have an additional 6(?) things in the FRAMEKINDs enum. This would explode by a huge amount as I have more frame types, or if I allow more than 2 frame types to piggyback each other. Would you use bitwise flags (I think that's what they're called) instead? Thanks

ANONYMOUS wrote: Either way can work - the best way, initially, is the way that simplest for your to implement and get working. If your frame-types are mutually exclusive, you can give them all distinct values, and just store one of them in a header field. With piggybacking, you'll also need multiple (2) fields fro sequence-numbers, as both data and acks have a sequence. Not out of scope, at all. Here we have a situation where a frame may be carrying data, an ack, or both. So we can use constants that are powers-of-2 to represent multiple possibilities: #define DATA 1 #define ACK 2 #define DATA_ACK (DATA | ACK) // is 3 = 1 + 2 or, more confusing, but easier to edit/extend: #define DATA (1<<0) #define ACK (1<<1) #define DATA_ACK (DATA | ACK) // is 3 = 1 + 2