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(several 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

Perhaps, but probably not. How do you know how many senders you're going to have? Do you create a new thread everytime someone new comes along? Also, wireless networks are exceptionally prone to coming and going on/offline as a result of mobility, RFI, etc. Multi-threaded applications can add a lot of needless complexity to an application, particularly one that is...



...bound to a Universal Asynchronous Receiver Transmitter (UART)...assuming that you're using a typical, PC serial port that isn't synchronous serial enabled.

Basically, your serial port code will have to dispatch or "route" data to its consumers. In this case, a separate thread may be useful, since it can be configured to only run when it has data to work on.

I'd probably create a "router.c" that opens/closes/reads/writes to the serial port, probably /dev/ttyS0. I'd want one and only one reader/writer controlling accesses to the serial port.

I'd make router.c able to accept connections from consumers of the data traffic such that they provide their network address or other descriptive information to the router so that it knows to whom it will give the data.

Since most UART-based serial data is incredibly slow compared to a typical Linux PC CPU performance, I don't think that there is much value to using multiple threads for routing traffic, however, a separate thread for all traffic may be useful so that "router" can interact with new requests, changes in consumer "interest" in data traffic, etc on its main thread without (apparently) slowing down or blocking due to routing functions.


This seems like a very interesting project. As for GUI in C, I'd probably try to find out what that really means. If you're going for the WOW effect, OpenGL is probably the biggest bang you'll get as it will provide a programmatic means for 3D rendering of network traffic, routing links, node info, etc...but it is also very complex. OpenGL is also probably the most likely career-oriented and useful package. There is a LOT of need for OpenGL programmers in the gaming space both at the desktop and embedded worlds. Additionally, many major scientific applications across all lines of industry are using OpenGL for data visualization.

X lib intrinsycs are viable, but very low-level. Depending on the toolkit(s) used, it can look rather bland/obsolete, though. Still, it requires a lot of work for most applications. Just about nobody is using this in "real life" so learning it is probably not a good career move unless you happen to like living in the past.

ncurses is a "text mode" like graphical user interface reminiscent of the days of DOS and is easy to program, but not much WOW factor. It is probably the easiest choice for "basic" windowing, but won't do much for you if data visualization is intended.

Gtk is probably the only really viable solution if the C requirement is enforced and a "robust" GUI is desired/required. See: http://library.gnome.org/devel/glib/stable/

...and browse through the online API documentation to see if this will work for you.

Personally, I'd probably try to get a waiver on the C requirement for the GUI and use Qt. If I *had* to use C, I'd try to get a waiver that said that I could use Qt with the OpenGL Widget (QOGLWidget) and write OpenGL C code inside of the C++ "Windowing" world.

It kind of depends on what features are needed by the application. My choices are based on what I already know, though. I already know Qt and OpenGL and I'd be looking for ways to cut some time out of this rather expansive set of requirements. But that's me. You may have a different set of motivations.


MxB

Thanks for the reply.

I think now a thread for each Sender is a bad idea too.

By the requirements I mentioned in my post, the Driver software is running in Linux PC. The "Driver" node is connected to the PC using serial port. The stack runs on the "Driver" node while the application layer runs in the "Driver" software. Fragmentation is implemented in the Application Layer.

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 for this new requirement?

Thanks