Example: Creating a client/server pair using RFCOMM
This tutorial shows you how to create a simple client/server pair using the RFCOMM protocol, where:
The server MIDlet receives messages from any connected client MIDlet. The server "echoes" received message back to all clients (including the original sender). This allows the user of a client MIDlet to send a message to all clients connected to a server.
The user of the server MIDlet can send a message to all clients connected to the server.
With the help of this tutorial, you can build the example from scratch and familiarize yourself with some common features related to the Bluetooth API. Alternatively, you can download the example files and run them immediately with your Symbian SDK for Nokia devices (S60 3rd Edition or later). For more information on importing, building, and running Java projects, see Getting started.
The following figure illustrates various roles of the client and server MIDlet applications at different levels.
Figure: Different roles of the client/server application pair (at various levels)
The example is also provided on Nokia Developer. Instead of creating the example from scratch as shown in this document, you can download the example files and run them immediately with your SDK.
Naming conventions
In the example MIDlet presented in this document, we have chosen to name the “client” and “server” MIDlets based on their application level (client and server) roles and relationship. This naming convention has the advantage of being independent of the network connectivity used (for example, if one someday changes a MIDlet to use an alternative network bearer, the client/server relationship and related naming convention do not necessarily have to change).
This convention may feel a bit more “natural” for some types of applications (for example, multiplayer games over Bluetooth). However, it is worth noting that one can also easily find examples of other Bluetooth based applications, where the naming convention for the client/server pair has instead been made at the JSR-82 / Bluetooth connectivity level. Using the latter approach would reverse the naming convention (of which MIDlet is called the “client” or “server”) when compared the convention used in this example. In the design phase for your own MIDlets, this may be one topic to consider. Since you might choose either approach depending on your point-of-view, it may be useful (to avoid confusion) to clarify in your design documents why a particular approach and terminology was chosen.
Required connections
Several "client" instances of the MIDlet are started in different Bluetooth MIDP devices. (These will be Bluetooth slaves.) Each client MIDlet waits to accept a connection from an appropriate remote "server" MIDlet.
The server MIDlet first performs a device inquiry. When the device inquiry has completed, the server has a list of possible nearby Bluetooth devices. It then performs service discovery on found devices having a suitable COD (that is, mobile phones). This allows the server to find reachable nearby clients.
After the service discovery phase has completed, the user of the server MIDlet is presented with a list of devices (having the right COD) where the client is available. The server MIDlet next initiates a connection to each client selected by the end user. The user of the server MIDlet selects which client to initiate a connection to and the order in which connections are created (that is, the connections are created from the server to clients, one by one). The server is the Bluetooth master for each connection.
Figure: Device inquiry, service discovery, and connection creation
Client/server connections
A connected client MIDlet may send a message to its server MIDlet. The server simply echoes the message back to all connected clients. The message is also echoed back to the original sending client (just to keep the server MIDlet code trivially simple). This allows a client to send a message to all connected clients via the server.
Another alternative is that the server sends a "non-echo" message to all connected clients.
Figure: A client sends a message and the server sends that message to all clients
Dropped connections
If a client MIDlet exits or otherwise disconnects, the server remains connected to and in communication with the remaining clients. However, if the server MIDlet exits or otherwise disconnects, then all communication is lost between the clients (that is, all connections to the server are closed).