Multipoint Request/Reply Implementation

SCP make a broadcasting search requests from peer A(requestor) to peers N. When peer N1 matches on the search term, it sends the match to Peer A, not all the peers in the group. The messaging model imply in a request/response model. We decided have two channels: one to broadcast requests to peers N, and another to receive responses - only to requestors. The request message should contain a Return Address that indicates where to send the reply message. A simple solution was get ID of the requestor, using method getFromContainerID() in IChannelMessageEvent, and send the response using sendMessage(ID receiver, byte [] message), which sends to a particular receiver container. Any peer that wants to respond can simply initiate a direct connection with the requestor. Figure 1 shows this scenario.

A peer(replier) receives several messages from different others peers(requestors). Each replier needs to deal with these several messages(requests), then a Produce/Consumer mechanism was developed into each peer. This mechanism stores in a message queue, each message(request) received. A Consumer look at messages inside the message queue, where each message is consumed, and the respective requestor(for each message) will receive the response. Figure 2 shows this scenario.

Different Strategies for consume(Consumer)

This subsection will describe the possible strategies to consumer.

• Every message that a peer receives is added to a queue(request queue), and consumed. My greatest concern is performance, so I thought about three strategies to deal with this point:
  1. A timer(it was implemented, but I need to make more tests), that consume a message in the request queue by 30 seconds, over and over, while exists messages in the queue. I intend to use Eclise Job. At first glance, there is not significantly different from using the Thread class. However, the difference lies in some of the additional facilities provided by the Job class.
  2. A thread that consumes one message each time, while exists message in the queue, but the request queue could be setup, by instance 10 messages in the max size.
  3. Using several threads, where each message received, is supported with a thread that consume this message. I thought to implement these 3 strategies, and make a preference page where the Eclipse user setup his choice.