I won't provide you with a professional answer since I'm not in the RF field, but... spam sending an integer over and over? Jamming? That's no way of doing communication. You should send data along with meta-information.
Let's assume you have 4 devices sending information. That means you need 2 bits of information about the device. So the first two bytes will contain information about which device sent it. 00 - first device, 01 - second, 10 - third, 11 - fourth.
You shouldn't stream data all the time, too. Your hardware should be protected against noise to a certain extent, so you don't need a hundred thousand redundant bytes sent through the RF link. A single byte sent through UART<->RF should take you a couple tens of microseconds. If you don't need high speeds, you can afford to attempt sending this data a few times.
The transfer of data should go thusly:
- Device #1 sends a byte of data to device #2
- Noise prevents the byte from being successfully sent, device #2 is just standing there oblivious to the fact.
- Device #1 waits a bit for a response from device #2. If timeout is exceeded, another attempt is made.
- Let's say device #2 received a byte, but the checksum doesn't add up. It now sends a predefined error byte.
- Device #1 received an error signal, so it sends the same byte again.
- Device #2 received the correct byte, so it sends and Acknowledged control byte.
- The noise disrupts transfer yet again! So device #1 sends the byte yet another time. Perhaps it should include an ID? This way device #2 won't interpret this as a completely new byte.
This is a very chaotic description of what I imagine should happen in a very rudimentary communication system that is prone to errors. In order to create a reliable system from scratch, you should create your own protocol. Redundancy is only one of the ways of achieving this.
If you intend to send a large chunk of data, and the transfer takes a few milliseconds, there might be a chance another device will attempt to start its own transfer. However, that device should also be capable of checking whether the 'ether' is free. If it detects transmission, it should wait until it's finished.
This is such a fascinating topic that someone, somewhere has probably created a very well thought out protocol. There is probably a library on avrfreaks that will fit this application. Maybe there are industrial solutions you could mimic. What is certain is that this is not a simple matter.