ANONYMOUS wrote:
> 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?
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.
> 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?
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
