2.4 Illustrative Examples
2.4.1 Basic Distributed Applications
One of the strengths of the provided networking abstractions lies in their low threshold.
With just a few blocks, novices can develop an application demonstrating interesting con- cepts such as mesh networking or basic client-server architecture. These simple applications can make programming more social and provide more opportunities for discussions about distributed concepts such as resilience, security, and encryption.
Chat Application
Chat applications provide an easy introduction to distributed programming. They re- quire virtually no coordination between clients and can be achieved with a very simple pro- tocol. Using the provided programming abstractions, there are a number of different ways to implement a chat application. The entire application can be implemented within a single Room with a fixed set of Roles or the individual client applications can be implemented as individual applications which use the Public Role IDs for inter-room communication. Us- ing inter-room communication is more flexible and allows the chat application to support a dynamic number of clients. However, supporting these clients introduces some additional complexity as it requires the logic for managing client connectivity including the connection
and disconnection of clients. As this example is highlighting the basic distributed applica- tions, we will present a chat application supporting a fixed number of clients defined as the Roles in a single Room.
In this chat application, each Role can chat with the other Roles in the Room. A chat message contains both the message and the username of the person sending the message.
That is, the applications define a custom message type called “chat” which contains two fields: “name” and “message.” After defining this message type, the Role can easily send a chat message to the Room using thesend msgblock as shown in Figure 38. In this example, the message is broadcasted to “everyone in the room.” This ensures the user’s chat message will be sent to every Role, including that of the sender.
Figure 38: Sending Chat Message
In addition to sending messages, each Role will need to listen for the given message type and display the content of the chat message. Although each Role can certainly display the messages in a multitude of interesting and creative ways (such as printing each message in a scrolling window on the stage), a basic technique is shown in Figure 39. In this figure, the given sprite simply displays the most recently received chat message. The message is formatted with the sender’s name preceding the message contents and separated with a colon.
Figure 39: Receiving Chat Message
This is an example of a relatively minimal distributed application. Messaging in this application is simple as there is only a single message type, “chat,” and messages are al- ways broadcasted to all Roles in the given Room. Each Role displays the last chat message and every Role shares the same identical code. Although this example is simple, it demon- strates how a basic distributed application can be created using only four command blocks.
This simplicity highlights the low threshold for developing distributed applications using the provided abstractions.
Mesh Networking
Our second basic example is a mesh networking application. Like the chat project, this example demonstrates the low threshold for developing distributed programs. Both exam- ples provide an accessible, working example demonstrating some basic distributed concepts.
These examples are also a foundation for motivated students to explore more complex dis- tributed computing concepts such as resiliency and security.
In this example, users can form small mesh networks and send messages to other users in the network. First, users will define the physical layer of the mesh network by setting the fully qualified address of the application to which it can send messages. We expect the applications to form a ring in which one has a connection in the physical layer only to the subsequent node in the ring. After defining the physical layer, each application can send a message to another node in the circle using a logical address, such as the username of the intended recipient. Each individual application then contains the logic for routing each message with respect to the logical address of the intended recipient.
In this example, “next node” is the fully qualified address of the connected node of the given application. This represents the connected node in the physical layer of the mesh network. Every “mesh” message contains three fields: “sender,” “receiver,” and “msg.”
The “receiver” field defines the logical address of the intended recipient. The “sender” field defines the originating sender and “msg” defines the contents of the message.
Figure 40: Sending Mesh Message
Figure 40 shows an example of sending a message in the mesh network. When sending a message, the user must provide the logical address of the intended recipient. In this example, the logical address corresponds to the occupant’s username. The user also needs to provide the actual content to send, “msg”. After constructing the message, the application sends the message to “next node” as this represents the only connection in the physical layer of the network.
Figure 41 shows an example demonstrating the routing logic in the mesh network. When the application receives a message from the mesh network, it will first check if the current
user’s username matches the intended recipient. If so, then the message will be displayed to the user. Otherwise, the message will simply be forwarded to the next node in the mesh.
Figure 41: Receiving Mesh Message