Overview
- RabbitMQ roles
- One-VM echo and ping-pong samples
- Cross-VM communication
- Shared queues and fanout
Start with Required Architecture Overview for the project roles and RabbitMQ-only internal boundary
RabbitMQ Between Programs
Your sample programs send and receive messages. RabbitMQ is the separate broker service between them
The exchange routes a publication to a bound queue. The receiving program consumes from that queue. An SSH session gives you access to a VM; it does not carry the sample message between programs
Watch Echo And Ping-Pong
The individual practice asks you to observe both behaviors in the supplied sample programs:
| Sample behavior | What to look for |
|---|---|
| Echo | A recognizable value returns to the program that sent it |
| Ping-pong | The programs continue a back-and-forth exchange |
Observe both programs during the same run. These are small RabbitMQ communication checks, not proof of a broadcast or the full project workflow
One VM, Two SSH Sessions
- Run RabbitMQ and the assigned sample programs on the same practice VM
- Use separate SSH sessions so you can observe the sending and receiving sides
- Follow the supplied
RabbitMQServerSample.phpandRabbitMQClientSample.phpin the IT490-2026 code - Look for a recognizable value at both ends of the exchange
The individual worksheet gives the required setup and evidence details. This first run checks the local path before adding a second VM
Follow One Sample Message
Suppose the test value is probe-17. This is an illustrative marker, not a claim about the supplied sample's exact output
| Observation | What it supports |
|---|---|
The sending program reports probe-17 | It attempted to publish the chosen value |
The receiving program reports probe-17 | The matching value arrived through the local RabbitMQ path |
| Both programs ran on one VM | The network path between two VMs remains untested |
Match the value and the run, not just two unrelated success messages
What Did The One-VM Result Prove?
Two SSH windows show a successful send and receive. Does that prove the sample works across VMs?
No. It proves the local broker and sample path used in that run. The sender and receiver have not crossed a VM network boundary yet
That distinction tells you exactly what the group practice needs to test next
Move The Sample Across Two VMs
- Put the broker and server sample on one practice VM
- Run the client sample from a teammate's practice VM
- Connect the sample to the intended RabbitMQ host and repeat the recognizable test message
- Observe both ends of this same run before claiming cross-VM success
The group worksheet specifies the setup script and individual demonstration evidence. The practice VMs test communication; the later named role VMs serve the logging milestone
What Changed Across VMs?
The message now has to cross a network boundary to reach the broker
| Check | What it can tell you |
|---|---|
| SSH reaches the other VM | You can access that machine; the RabbitMQ connection is still unproven |
| The remote sample connects to RabbitMQ | The broker endpoint is reachable from that VM |
| The matching value appears at the receiving side | This run completed the intended cross-VM message path |
Keep access, connection, and delivery as separate claims
Troubleshoot A Missing Message
Find the first boundary that fails, then check that boundary
| Problem | First useful check |
|---|---|
| You cannot reach the other VM | Confirm its address, SSH access, and network reachability |
| The sample fails even on one VM | Check that RabbitMQ is running and the local sample settings agree |
| The local run works, but the remote run fails | Check the remote broker address, credentials, and permitted connection |
| A program says it sent, but nothing arrives | Check the exchange, queue binding, and receiving program before claiming delivery |
Change one suspected boundary at a time and rerun the same test value
Two Consumers, One Queue
Two consumers (receiving programs) listen to the same RabbitMQ queue
Will both receive a copy of every message?
No — the consumers divide the deliveries
- RabbitMQ sends each delivery from that queue to one consumer
- If Consumer A receives
log-17, Consumer B does not get a separate copy from that queue
This distributes work between consumers
The logging system needs every role VM to receive each event
Fanout Gives Each Queue A Copy
A fanout exchange routes a published message to every queue bound to that exchange. Each listener has its own queue
If both queues are bound and both listeners consume their own queues, each has a delivery path for the same event. The binding and queue layout, rather than extra SSH windows, create the broadcast behavior
Next: Fanout Logging On Role VMs
The next milestone turns the sample message path into a logging proof of concept:
- A test caller publishes a new log event through RabbitMQ
- The App, DB, MQ, and API role VMs each have a distinct delivery path
- Each role VM appends its received event to its own local log file
- The test callers exercise reusable logging helpers; application integration comes later
The Module 2 samples establish basic RabbitMQ communication. They do not yet establish fanout or four local log copies
Knowledge Check
Questions
- What routes a published message to a bound queue?
- Why does a successful SSH connection not prove RabbitMQ message delivery?
- Do two consumers sharing one queue each receive every message?
- What does a fanout exchange do with a message when several queues are bound to it?
Answers
- The RabbitMQ exchange routes the publication according to its bindings
- SSH proves machine access; the sample must connect to RabbitMQ and show the matching received value
- No. They share deliveries from that queue rather than each getting a copy
- It routes a copy to every bound queue
Use Next to reveal each answer
Key Terms And Further Learning
- Broker: the RabbitMQ service between sending and receiving programs
- Exchange: the broker component that routes published messages
- Queue: a delivery path from which a receiving program consumes
- Binding: the connection that lets an exchange route to a queue
- Fanout: exchange behavior that copies a publication to every bound queue
- Further learning: RabbitMQ exchanges and queues
Summary
- The one-VM sample checks a local RabbitMQ message path
- The two-VM sample adds the network boundary and needs matching send and receive observations
- Consumers sharing one queue divide deliveries; a fanout exchange with distinct bound queues gives each queue a copy
- That distinction prepares the next logging proof of concept on the App, DB, MQ, and API role VMs