In the following document, all times are in microseconds. Your program will use type "long" to represent most such values (although some items such as packet lengths, which are the same value whether in bytes or in microseconds for our assignment, can be of type int, if you prefer).
There are different ways in which transmissions can conflict, which have different impacts. If the planned starting times for two transmissions are within two microseconds of each other, inclusive, then they won't merely conflict, there will be a collision. That is, each host will be transmitting on the network at the same time. This means that neither host's transmission is successful, and they both need to retry; thus you will have to distinguish this from the case in which the start time differs by more than two microseconds. If the start time differs by more than two microseconds, the second host will detect that the first host's transmission has already begun, and won't even attempt to transmit. Thus the first host's transmission will be successful, and only the second host needs to apply the retry formula.
As usual, you will keep your event queue in sorted order based on the next time at which that host is going to attempt transmission. (Thus it is, to be precise, a "priority queue", not a queue.)
Where the collision/conflict detection comes in is in the processing of this queue. Before determining a packet transmission to be successful, you have to look down the queue, and see whether any other packet transmission will conflict with this one. If it is a conflict which is not a collision, then you need to mark that other packet as conflicted. If it is a collision, then you need to mark both packets as having been involved in a collision.
Each object in the event queue will thus need additional data members which keep track of whether or not it is involved in a collision (for this planned next data transmission; you reset this when rescheduling it for a subsequent packet transmission), and which keep track of whether or not it is involved in a non-collision conflict.
When you go to process the top item in the event queue, if it is already marked as being involved in a conflict which is not a collision, then it won't even attempt to transmit, so you simply reschedule it; it will not cause further collisions or conflicts.
If the top item in the event queue is marked as being involved in a collision, you will still need to compare it to some further packets down the queue.
Note that during this collision/conflict detection, you are not popping items off the queue. You are traversing the queue as a linked list, comparing its list members with the data found in the object which is at the head of the queue. You must be sure not to pop an event off the queue until you have recorded all of the effects of its transmission (if any).
The comparison as to whether or not two packet transmissions conflict can be simpler than your formula for live_range_is_overlapping() in assignment two, because you can arrange it so that you know that you are dealing with the object at the top of the event queue, and thus any other events are later in time or equal in time to the current one. So you just have to see whether the start time of the later object is within my_start_time to my_start_time + my_duration.
By the way, in my solution I do not delete objects. I just move
around the linked-list pointers. I think that this is probably a much easier
way to do it because then the objects can retain state between multiple
enqueueings.
If the following question/answer is incomprehensible now, ignore it until it comes up for you:
Q: When the top item in the event queue is marked as being involved in a collision, how long do I consider that collision noise on the network to tie up the network? It will not be as long as the original planned packet size, right?
A: Right. This should have been specified in the assignment handout. In the absence of clarification, I imagine that most students will use 2 microseconds as the value. However, this doesn't really make sense. It seems to me that the network is jostled for at least one byte time after the later transmission starts. Perhaps we should say that the collision runs for a further 2 microseconds, for a total of 4 microseconds from when the first collider started listening until the network is clear again. (Either will be accepted in grading.) Or from when the last collider started listening. You can do whichever you find easiest, since it was not specified.