Linux Wireless Network Testbed

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • james457
    New Member
    • Jun 2009
    • 6

    Linux Wireless Network Testbed

    Hi all,

    I am writing a linux testbed for wireless sensor networks. The core objective is to test data transfer between any two nodes. The network runs using tree topology.
    One node in the network is the "Driver". This node is connected using serial port to a linux PC. What I am trying to write is the software on this linux PC that will drive data transfer in the network.

    The "Driver" node, taking commands from the software running on linux PC, will send out data request message to a Sender node. The Sender node will parse the data request message and commence data transfer to the "Driver". Multiple such Senders can exist. All data transfers is from the Senders to the "Driver" node. The "Driver" node passes all the data it receives to the linux application. The linux application keeps track of how many packets have been received from the different Senders.

    Following are the requirements.

    1. Any node in the network can be the driver (destination) and any node can be the Sender.
    2. There can be multiple Senders at any give time, sending data to the "Driver" node.
    3. The data received from serial port and sent by serial port by the linux application are logged to a file.
    4. The linux application should be able to read data request messages from a file and send them out at specified times.
    5. A GUI for this linux application. All the code with be in C, so the GUI choice will have to place nice with C.

    One final twist: the data from Sender to "Driver" is fragmented data. On the Sender side fragmentation is handled in the device itself. On the "Driver" side fragmentation will be handled in the linux application. So the linux application will have to keep track of the fragmentation window and send fragment ack for each of the data transfer going on with the multiple senders, and keep track of the number of packets received so far from each Sender.

    So in the linux application, is the way to go having multiple threads - one thread for each Sender? Will multiple threads play nice with one serial port for
    sending and receiving simultaneously?

    Advise on any requirement will be appreciated. The basic idea is to test data transfer, especially data gathering(sever al nodes sending data to one node) . If a different approach than outlined above is suggested I am more than welcome to hear them too.

    Thanks a bunch

    James
  • donbock
    Recognized Expert Top Contributor
    • Mar 2008
    • 2427

    #2
    You mention that any node can be the Driver.

    Can two or more nodes be the Driver simultaneously? If not, how do you arbitrate Driver-ness? That is, how do you move Driver-ness from one node to another?

    The following questions are only meaningful if two or more Drivers are allowed at the same time ...

    Even if two nodes are allowed to be driver simultaneously, it is unlikely that they are both allowed to talk to the same Sender at the same time. How do you arbitrate access to any particular Sender?

    Can one node be both a Driver and a Sender (responding to some other Driver) at the same time? Can a pair of nodes be both Driver and Sender to each other?

    Comment

    • james457
      New Member
      • Jun 2009
      • 6

      #3
      You mention that any node can be the Driver.

      Can two or more nodes be the Driver simultaneously? If not, how do you arbitrate Driver-ness? That is, how do you move Driver-ness from one node to another?

      There can be more than one Driver at a time.

      The following questions are only meaningful if two or more Drivers are allowed at the same time ...

      Even if two nodes are allowed to be driver simultaneously, it is unlikely that they are both allowed to talk to the same Sender at the same time. How do you arbitrate access to any particular Sender?

      A Sender at any time talks to only one Driver. This has to taken care of by test case design - chosing offline which Driver is going to request data from which Sender.

      Can one node be both a Driver and a Sender (responding to some other Driver) at the same time? Can a pair of nodes be both Driver and Sender to each other?

      No a node cannot be Driver and Sender at the same time.

      Comment

      • james457
        New Member
        • Jun 2009
        • 6

        #4
        I am thinking of a slightly different requirement. I want to run all the nodes on a single PC. The software should drive the entire network. The network will have multiple Drivers and Senders. A node cannot be Driver and Sender at same time though.
        A Sender will only talk to one Driver at a time. I am thinking of having one process that reads data from all serial ports. I think I can go with select() for non blocking I/O and read/write from/to several serial ports.
        Now how do I run each driver? Is it better to have each driver as a process or a thread? Any other different architecture in mind?

        Comment

        • donbock
          Recognized Expert Top Contributor
          • Mar 2008
          • 2427

          #5
          Originally posted by james457
          Even if two nodes are allowed to be driver simultaneously, it is unlikely that they are both allowed to talk to the same Sender at the same time. How do you arbitrate access to any particular Sender?
          A Sender at any time talks to only one Driver. This has to taken care of by test case design - chosing offline which Driver is going to request data from which Sender.

          Can one node be both a Driver and a Sender (responding to some other Driver) at the same time? Can a pair of nodes be both Driver and Sender to each other?
          No a node cannot be Driver and Sender at the same time.
          An important aspect of test design is to sweep out those corner cases and verify that the software properly handles exceptional conditions. You want test cases that provoke both of those exception cases.

          Bugs in the nominal functionality are quickly found and fixed; but bugs in the exception handlers only manifest sporadically and tend to not be repeatable -- they tend to stick around.

          Comment

          Working...