The short answer is that the node must monitor the CAN lines to be idle for a certain time before it attempts to transmit. So if another node is transmitting, it must keep quiet till the other node is done.
A CAN bus is based in differential signalling. The two lines, CAN-High (CAN+) and CAN-Low (CAN-), are both at the same potential when the bus is idle. To send bits, a CAN transmitter puts a differential voltage on the lines of about 2 volts.
A CAN transmitter first sees if the bus is idle and if it is, starts to transmit. How the arbitration works is that a transmitter monitors the bus as it's transmitting. Transmission is done as above by either keeping the two lines at the same potential or at a differential potential. So if the transmitter transmits a bit by keeping the lines at the same potential (sic), but it sees that the two transmit lines have a differential potential, that means that some other node is transmitting and the first transmitter has lost the arbitration. It must then stop transmitting.
When a node first starts transmitting, the bits transmitted are the same until the address of the transmitting node which are obviously different. If two nodes start transmitting together, they will transmit together in sync till the address part is reached. When the address differs, a node will notice a potential difference on the lines even when it is not putting one on the lines. Then it knows it has lost and has to try again. The winning node continues transmitting without knowing that some other node was trying as well. Of course, this logic extends to more than two nodes also.
I hope this helps.
Section 6.1 of the CAN spec:
BIT ERROR: A unit that is sending a bit on the bus also monitors the
bus. A BIT ERROR has to be detected at that bit time, when the bit
value that is monitored is different from the bit value that is sent.
An exception is the sending of a ’recessive’ bit during the stuffed
bit stream of the ARBITRATION FIELD or during the ACK SLOT.
So, the node which first transmits a '1' when the other is transmitting a '0' will note a Bit Error and then signal an error as normal - by transmitting an error-flag (see Section 3.1.3) , as described formally in Section 6.2.
Informally, if that node is error-active (which should be the usual case) it will transmit an error flag of 6 dominant bits, which all other nodes will also detect (as a stuff error). This has the effect of destroying that message completely:
- no-one will receive it
- none of the transmitters will think they have successfully transmitted anything.
Each transmitter will then attempt to retransmit - depending on the precise timing of the retransmissions, one may start sufficiently before the other the gain control of the bus. Otherwise, the same sequence may happen again. (Or another higher-priority message may put them both off for a while!)
Extended answer inspired by @clabbacchio's answer below.
You mention "nasty nodes", and clabbacchio makes the valid point that if two nodes transmit at different times, each receiver needs to decide what to do with its multiple receptions.
This was demonstrated by a hack last year. The paper discusses, in the section "PSCM specifics", how an attacker can synchronise to the regular messages on the bus and play their evil message just before the one that the "good" ECU is about to send. The receiving ECU accepts the earlier message, updates its message counter and then discards the "good" messages as erroneous, because its message counter has not incremented.
Best Answer
First of all the basic CAN transfer mechanism is:
Any node can initiate a transfer.
If a node wants to transmit and the bus is busy it waits until the end of the current packet.
If two nodes start to transmit at the same time then the message with the lower ID will take priority, the message with the higher ID will abort, wait until the bus is idle and then try again.
Most nodes will be configured to generate an ACK pulse at the end of every valid packet they receive. This doesn't mean that they will do anything with the packet, just that they read a valid packet and checksum. Multiple nodes can all generate an ACK for the same packet without any issues (normally every device on the bus will). If the transmitter doesn't see any ACK pulse it will indicate to it's controller that there was a transmission error.
There is nothing about a CAN bus that requires the system to keep transmitting no matter what or to only transmit when requested, that is entirely up to the software controlling the messages. All the CAN bus requires are that the bus has at least two nodes, the correct bus termination, and that the nodes are configured such that at least one node acknowledge every packet.
There are other standard protocols that can be used on top of CAN (e.g. ISO 15765-2) to control message transmission in a request/reply structure but they are entirely optional. Whether it is best to just blast messages out, use a standard protocol, use your own protocol, or a mixture of the above depends entirely upon the application in question.