- This topic has 6 replies, 1 voice, and was last updated 7 years ago by Kalman.
May 21, 2015 at 5:33 pm #784Philipp GiesenGuest
I am currently building a monitoring application on top of the overlays used in the simulator. This application requires to send messages containing application data from one overlay node to another (specific) node within the overlay.
Let’s take Chord as an example.
Currently I’m using the method route(ChordKey, Message, AbstractChordContact) defined in the class AbstractChordNode to send a message to an overlay node. This method wraps the message within a KBRForwardMsg and sends it over the TransLayer to the next hop.
For receiving this message I built a MessageHandler implementing the interface TransMessageListener. This message handler registers itself as a TransMsgListener via the addTransMsgListener(TransMessageListener, short) defined in the interface TransLayer.
I now find my application message wrapped within a KBRForwardMsg at the messageArrived method within my message handler. The problem is, this KBRForwardMsg containing my data only arrives at the first hop addressed by the route-method. Further hops (including the adressed receiver of the application message) are not notified by their corresponding message handlers.
The Javadoc of method route clearly states, that the message is forwared to the root of the given key. However, looking at Chord, that seems not to be the case.
I assume, I have to not use the route-method from AbstractChordNode (as Chord is not able to forward information) but the route-method of KBR. However, I am not sure of how to achieve this, since I only have a ChordNode (respectively a host-object, which is a ChordNode in fact) within my application I can refer to.
Any suggestions of how to send and receive application messages the correct way?
Thanks!May 21, 2015 at 5:34 pm #785Matthias FeldottoGuest
thanks for your interest in our simulator.
In general you are on the right way, the KBR interface provides the correct functionality for your purposes. It is implemented by Chord and normally it should work (no guarantee, but I’m pretty sure).
In your case, the problem probably is with the correct use of the KBR methods. Please look at the FileSharing application with the KBRHandler or the KBRLookupGenerator, both take use of the KBR interface and should be a good help for you.
If this doen’t help you, please write again.
MatthiasMay 21, 2015 at 5:34 pm #786Philipp GiesenGuest
thanks for your quick answer. I now tried that approach and implemented the interface KBRListener as made by the FilesharingApplication within the class KBRHandler. If the node is responsible for the key the message shall be sent to, I call the deliver method and if it’s not I’m routing through the KBRNode.
The overlay used is still Chord only.
The routing seems to work, since the forward-method is called twice (at first and second hop), however, the message is not delivered to the receiver (the third hop) responsible for the key the message is sent to. The deliver-method is never called.
I’ve read the documentation but I’m unsure, why the delivery would not work. Do you have any quick suggestions what might be a problem?
Thanks in advance
PhilippMay 21, 2015 at 5:34 pm #787Philipp GiesenGuest
Okay, I found the solution. I modified the method messageArrived() within class KBRMsgHandler to accept messages from my Application. Currently the method only checks for instances of KBRLookupMessage. All other messages arriving at the target node are disregarded. Is this behaviour intended?
PhilippMay 21, 2015 at 5:35 pm #788Matthias FeldottoGuest
yes, that is correct, the KBR methods only handle KBR messages. One can discuss, if this is the best way, but it is the current implementation.
But instead of modifying the KBRMsgHandler (what is also possible and should work), you can simply mark your own message implementation with the KBRMessage marker interface. Let your message class just implement the interface org.peerfact.api.overlay.kbr.KBRLookupMessage (pay attention, there exists a class with the same name) and it should be delivered correctly.
MatthiasMay 21, 2015 at 5:35 pm #789Philipp GiesenGuest
thanks for your suggestion, but what if my application wants to be independent from the network overlay used. Say I want to send messages within my application on a gnutella overlay.
It seems odd to implement different types of messages on my application layer, when the actual used network overlay in the simulation is unknown to the application (and only managed by different overlay handlers like in the filesharing application).
PhilippMay 21, 2015 at 5:35 pm #790KalmanGuest
Just to add some further insights,
the said application is a monitoring mechanism, which uses the contacts in overlay to exchange monitoring related message. For example, a gossip based monitoring solution is only interested in sending gossip messages over the existing links. Ideally, it gets the list of contacts from the overlay, irrelevant whether it is a KBR-DHT-overlay or an unstructured overlay and sends to a selection of these links a few messages.
Thus the application requires an overlay, in specific a set of open connections (the links to the neighbors), but does not further restrict the type of overlay.
How can one implement such an application best?
- You must be logged in to reply to this topic.