Skip to main content

Key Application Layer Functions

Constructor 
Can be use to set message to NULL. Better not to skip defining the constructor.

Destructor
Can be use to clear/delete messages using cancelAndDelete(). New version seems to be motivating to use a destructor so better not to skip.

void initializeApp(int stage)

Can be used to initialize the application, read parameters from omnet.ini file, set statistic collectors, GUI display variables, start timers, set UDP port, etc.
  • stage - Indicate which stage your are in. MIN_STAGE_APP indicates this module is being created while MAX_STAGE_APP indicates all modules were created. We typically need MIN_STAGE_APP to initialize application & variables.
    void finishApp()
    Called when application is terminating. Can be used to summarize stat. New version seems to be motivating us to delete messages in the destructor.
     
    void handleTimerEvent(cMessage* msg)
    Handle event timer. Use to generate new periodic messages, other events, or check for lost messages. Better not to generate messages until underlay is initialized (unless you need this specific behavior) 

    void deliver(OverlayKey& key, cMessage* msg)
    Handle messages delivered from overlay. Called only at the node that is believed to be the application responsible for the key.
    • key - Destination key
    • msg -  Dynamically cast msg before using because message type is cPacket. Delete msg if no longer needed. Latency can be determined from msg->getCreationTime(). Use control data (msg->removeControlInfo()) to extract hop count using getHopCount() method.
      void forward(OverlayKey* key, cPacket** msg, NodeHandle* nextHopNode) 
      Handle messages from overlay to be forwarded. Call in each intermediate node along the path. Can skip this if you don't need to do anything. Useful for appending list of visited nodes or to look up local cache. Also useful while implementing malicious nodes that drop messages.
      • key - Destination key 
      • nextHopNode - Node to be used as the next hop
      void handleUDPMessage(cMessage* msg)
      Handle messages delivered directly through UDP.
      • msg - Dynamically cast msg before using because message type is cPacket. Delete msg if no longer needed.
      bool handleRpcCall(BaseCallMessage* msg)
      Handle RPC call message from another node or upper layer. Use many predefined functions to easily handle the message.
      • Return true if RPC is handled
        void handleRpcResponse(BaseResponseMessage* msg, cPolymorphic* context, int rpcId, simtime_t rtt)
        Handle RPC response from callee.
        • msg - Use msg->getCallHopCount()to determine number of hops that call message took. Use control data (msg->removeControlInfo() or msg->getControlInfo()) to extract response message's hop count using getCallHopCount() method. To determine latency context->requestTime() can be used.
        • context - Pointer to an optional state object.
        • rpcId - RPC identifier.
        • rtt - Round trip time for RPC call & corresponding response.
          void handleRpcTimeout(BaseCallMessage* msg, const TransportAddress& dest, cPolymorphic* context, int rpcId, const OverlayKey& destKey)
          Handle RPC timeout event. Can be used to retry by generating new call or indicate failure.
          • dest - Destination node
          • context - Pointer to an optional state object.
          • rpcId - RPC identifier.
          • destKey - Destination key
          void BaseApp::handleNodeLeaveNotification()
          This method gets call when node waits some time before leaving (kill) the network. Delay in Seconds is set using **.gracefulLeaveDelay. Can be use to call any node clean up call & advice node not to issue any more messages.

            Comments

            Martin Ladecky said…
            Hi Dilum ( I hope, it is your first name :) ).
            At first, I would like to say thank you. Your articles about Oversim are great and very useful.

            I have some questions about it.
            There are 2 main layers in KBRTestApp -> overlay (it could be kademlia, pastry, whatever else) and application itself. Where is the line between these two layers? Or is there any line at all? I mean with communication. What is each layer responsible for? For example: each layer has method handleRpcCall. I'm not quite sure what should be taken care of in each of these methods.

            Thank you for any ideas.

            Martin Ladecky
            Dilum Bandara said…
            Yes. Overlay layer defines the overlay routing like Chord or Kademlia. Application layer defines the services that runs on top of overlay like DHT, multicast, etc. We tend to think DHT as the overlay. Actually, overlay is suppose provide routing while (key, value) indexing is an application layer function.

            In terms of implementation, line is defined whether you implement your code inside src/application or src/overlay directories.
            At each layer, you are expected handle messages send to that layer using handleRpcCall(). Which layer to send the message is indicated when you call sendRouteRpcCall().
            For e.g., if you say sendRouteRpcCall(TIER1_COMP, dest.first, call, context);
            it will automatically call handleRpcCall() in application (TIER1_COMP) layer. Also see Chord example.
            Sarwar said…
            Hi,

            I am new in using the OverSim and Omnetpp,

            I have A Question, that whether we can implement our project using only Applciation layer by not envoling Overlay layer,i.e. Connecting Applcaition Nodes, and Sending and Receiving Message by not envolving the Overlay layer.

            Thanks in Advance
            Dilum Bandara said…
            It may be possible. Just treat overlay nodes as application nodes & connect them the way you want. I may be able to give some hints, if you can tell what exactly you are trying to do.
            肖莎莎 said…
            Hi, I'd like to say that your blog about OverSim is so helpful and I am very appreciated your work!
            Thx again!

            Popular posts from this blog

            Python Code to Calculate Gini index/coefficient, Robin Hood index, & Lorenz curve

            Following Python code can be used to calculate Gini index, Gini coefficient, Robin Hood index, and points of Lorenz curve. Lorenz curve can be also plot if matplotlib is installed.
            It's based on the steps given by Peter Rosenmai.

            Download


            Other online tools:
            http://www.wessa.net/co.wasphttp://www.poorcity.richcity.org/calculator.htm

            1. Building P2P Simulators with OverSim - Where to Begin

            This could be a series of blog posts about extending or developing your own OverSim applications & overlay networks. OverSim has a minimal tutorial on writing your own application & overlay network; however, it doesn't show the big picture. So, I'm wasting lots of time playing with code & trying to understand the rest. Good thing is, I like it more & more as I understand. You need to change/develop only a few things, but finding out which ones is a hell of a task. I hope this will not only make my life easy but also will be useful to new comers. Here's what you need to do: You need some background on OMNeT++ OverSim extend OMNeT++. But sometime it has its own way of doing things (to make your task even simple) so understand the differences.Develop several OMNeT++ simulators. TicToc is a good one to start with. Extend it as you imagine.Read Towards a Common API for Structured Peer-to-Peer Overlays, which is the basis for OvseSim's API. Here'…

            Describing Experimental/Simulation Setup

            Sometimes the results of a performance analysis may depend on the computers used and/or specific features of software/libraries. In such cases it is extremely important to describe the experimental/simulation set up in details. It enables others to repeat those experiments as well as check whether the results are rigorous, statistically sound, and unbiased. Unfortunately, "Simulation Setup" is the shortest section in many research papers where authors try to save space by cutting down as much as details. Here are some tips on what to include (in addition to describing the experimental/simulation setup) based on my experiences:
            Type of Simulation Are the results based on Experimentation, Emulation, or Simulation? If simulations also mention further details like whether it is Discrete Event, Montacarlo, Stochastic, or Deterministic simulation. Are the results for Steady, Dynamic, Starting/ramp-up, or Terminating state(s)?Number of Experiments/Simulations No of sampl…