Almost ready for another release.

Hey guys,

Thanks to Doug helping us create a test app, we were able to verify that BlueMesh is working as expected after the code refactor.  We are going to do another week or two of testing before we go ahead and release our next alpha version just to ensure that everything is working as we want it to.

There are still a few small features we are going to implement (mostly optional arguments when building bms) that will be in the new release that we will be doing this week.

Support for Windows, Linux, and OS X will most likely not make it into this alpha, but we will have another alpha release soon after this one with all those features included.

Stay posted for exciting mesh networking news on BlueMesh!

Jerry

BlueMesh Test App

Hello,

As Jerry mentioned last week, I've been working on an application to test the basic functionality of BlueMesh. I'm still learning the Android API and the BlueMesh code base, so my confidence in my work is not astoundingly high. However, I have a first draft of something which is at least a good step towards working. I'll be spending the next couple of days making sure that it does what it needs to.

As of right now, I have the test results simply displayed as a Toast message. Ideally, I would like to set up a full graphical interface of some sort, with a list of the tests performed and checkboxes (or something) indicating whether each was successful. I'll also be looking to expand the set of tests as I get more familiar with what the service is capable of, and as the features themselves are expanded.

-Doug

New Developers

Hey Guys,

As you may know, BlueMesh has been in development for just over a year!  It began with a lonely group of one (me) and remained as such for about 4 months.  For the past 9 months Sean joined the team and we were two.  As of a few weeks ago BlueMesh has attained 2 new developers: Doug and Zach!

Over the next few weeks...

Doug will be working on writing a test application for BlueMesh that we will use to ensure that our master and dev branches are in a working state.

Zach will be working on updating our wiki to reflect our new API (sorry) and all of the new features that we are implementing.

Sean and I will be working on BlueMesh core functionality.  First we will be adding support for Windows and maybe Linux and OS X.

Contact us with any questions you may have,
Jerry

Builder Pattern

Hey guys,

I recently change BlueMesh so that when constructing BlueMeshService objects, rather than using a constructor method you now use a builder.  This makes it a lot easier to add new features to BlueMesh such as support for WIFI or other operating systems.  In addition, it is now a lot easier to configure BlueMesh to exactly how you want it.  Here is a short example of how it works:

BlueMeshService bms;
BlueMeshServiceBuilder bmsb = new BlueMeshServiceBuilder();
bms = bmsb.uuid(UUID.fromString("fa87c0d0-afac-11de-8a39-0800200c9a66"))
          .bluetooth(true)
          .build();
We will be updating the documentation to reflect these new changes soon and also have some new tutorials about how to use BlueMesh.

-Jerry

Another Code Restructure!

Hey Guys,

Over the next week I will be working on a code restructure of the entire project.  I will be abstracting all classes that are currently dependent of Android APIs so that they can be implemented for different wireless communication stacks.  I will also be making some of the larger and more complicated methods smaller and more readable.

After the restructure is done we will be adding support for the Windows Bluetooth stack and maybe another form of wireless communication.  In addition, we will be developing some new apps that use BlueMesh to demonstrate its capabilities.

Stay tuned for more updates!

-Jerry

Addition of Routing in BlueMesh

The traditional Android-only BlueMesh now has functionality to route messages to certain devices on the network. The "write" method now has two versions. The first takes only the byte array as before. The second takes the byte array and a RemoteDevice of some target, and sends the byte array only to that target, if connected at the time.

The routing done is similar to how messages are sent normally, only a targeted message will be ignored by all but the target. This allows for information to be routed only to one device on the network through other, unrelated devices.

The message packet is constructed in a different way depending on whether or not it is a targeted message or not. The old packet construction was allocated so that byte 0 was the message level, bytes 1-4 were a message ID, and bytes 5-1028 are the message itself. Targeted messages are now laid out so that byte 0 is the message level, bytes 1-4 are a message ID, bytes 5-12 are the target, and bytes 13-1036 are the message. Keep in mind these distinctions are controlled by the Constants file and can be changed if necessary. Specifially, the MESSAGE_ID_LEN controls the number of bytes long the message ID is. TARGET_ID_LEN is the length of the target identification, which is a byte array representing the Bluetooth address of the device. MAX_MESSAGE_LEN controls the maximum length of a message, currently set to 1024 bytes.

Message chunking has not been implemented and may not be, since the heuristics to making sure that all of the pieces get where they need to in order are difficult. Instead, increasing MAX_MESSAGE_LEN can be used for reasonable values. I do plan on doing some testing to find what is reasonable for this purpose.

The Agnostic project has been started, but I've run into difficulties in determining what exactly the interface should supply and/or be required to supply. Since different versions of Bluetooth work so drastically differently, it may be better to simply rewrite BlueMesh for a different device. Included here and below is the pertinent information for writing BlueMesh for J2ME, and I'm unsure as to whether or not that will be my next project or not. If anyone is using BlueMesh and is in need of it for a different platform, that may be my next project instead.

Until then, I may just continue testing and debugging.

Bluetooth Client and Server Information

In J2ME, the client in Bluetooth works through the DiscoveryListener interface. This means that the client-side must have some object that extends the DiscoveryListener interface. Meanwhile, the server has a DiscoveryAgent and does some things (as detailed in my last blog) to create an input-output stream between the server and client. However, the method for picking up the other (client) end of the steam was unknown. Below is a tutorial on how the J2ME client should look simply to get an input and output stream.

Note: Something followed by "()" is used to define it as a function in the API, but does not necessarily mean it has no arguments.

An action on the DiscoveryAgent on the client's side causes the four triggers in the DiscoveryListener, also on the client's side. To start, the startInquiry() method on the DiscoveryAgent will eventually call the deviceDiscovered() method in the DiscoveryListener whenever a server device is discovered. Then, the searchServices() method on the DiscoveryAgent finds services from the server and calls the servicesDiscovered() method once it has completed. This will return a ServiceRecord, which contains all the services that the server contains. To summarize, DiscoveryAgent.startInquiry() eventually calls DiscoveryListener.deviceDiscovered(), while DiscoveryAgent.searchServices() eventually calls DiscoveryListener.servicesDiscovered(), which contains as an argument a ServiceRecord.

This ServiceRecord can be used to be accessed all of the services, but the connection URL can be obtained with one line of code (Where servRecord is the instance of ServiceRecord):

String connectionURL = servRecord.getConnectionURL(0,false);

The URL returned is the RFCOMM URL that connects to this device. With this, a StreamConnection can be created with another line of code, which connects the devices and opens the stream between them:

StreamConnection con = (StreamConnection)Connector.open(connectionURL);

This StreamConnection can be broken down into an input and output stream, as in the server. These input-output stream pairs should communicate with each other, and will allow BlueMesh to pass data using the RFCOMM between the devices.

I am still uncertain as to whether the RemoteDevice's Bluetooth address or name should be used as a universal identifier to be passed to the router in BlueMesh. Both are easily accessible from the RemoteDevice. I am leaning towards the address, as the name can be duplicated, but I am unsure as to whether or not it is something that all API's (or at least the Android API) can also deliver.

Bluetooth ServerThread Interface Design

I've managed to work out BlueCove sufficiently enough to use it. Its syntax is identical to that of J2ME. J2ME is a version of Java that is designed to work with small devices, hence its built-in API support of Bluetooth. BlueCove, however, lets us use these same commands with J2SE (Standard Edition) and your basic computer running Windows or OSX.

I have also learned how to use these commands to write client-side and server-side algorithms to get devices to communicate. A useful, if slightly unclear, example can be found on CodeGuru.com. This gives us an input and output stream to work with. Since BlueMesh ultimately uses just an input & an output stream, this should be fine. However, BlueMesh's ServerThread currently passes a "BluetoothSocket" object instead, and that object is deconstructed to an input and output portion in the ReadWriteThread. So, BlueMesh is going to require a back-end redesign.

The ServerThread-like Interface will need to export an input and output stream. This is because the input and output streams are the lowest common denominator in the Android API and the J2ME API. The J2ME API gets these streams from the StreamConnection object, while the Android API gets them from the BluetoothAdapter object. Each object is specific to its own API, and cannot be included in an agnostic BlueMesh. So, the ServerThread will have to send only the input-output stream and some sort of device-identifying data (Device Name? Random Serial Number?) to the RouterObject. It will then be the RouterObject's job to find out if that device is already connected and to set up the ReadWriteThread for it.

Further, the way that J2ME handles clients is unusual. Specifically, it does not generate a BluetoothSocket object, so ClientThread will have to be reworked as well. The J2ME client is implemented with a virtual class, "DiscoveryListener", with four purely-virtual functions that are called when certain things happen, such as discovering a device. I am unsure as to whether or not this class is automatically a thread or really much about clients in J2ME at all. More research will have to be done.

Hopefully, I will just be able to extract from one of these functions/objects the input and output streams, so that the overall design of BlueMesh can be preserved. Otherwise, the ServerThread may be the only object able to set up communication and pass it to the router, meaning the client-side ClientThread will have to invoke the ServerThread to create two-way communication. I want to avoid this, so hopefully it won't be necessary.

Interfacing with others!

Hello, All! As detailed in the last post, BlueMesh will be trying to make the move towards greater compatibility. Specifically, we're looking towards creating a Java interface that will encapsulate all of the proprietary portions of Bluetooth. So, if you are willing to write an interface class for your platform, then BlueMesh will work on it.

That's the vision. Practically, BlueMesh will have to come with a couple of common interfaces. Luckily, I found another open-source project, BlueCove, that will allow Microsoft, OS X, and a few other platforms to do just that. Specifically, I no longer have to write code for these machines specifically; I can use this program as a bridge. More importantly, I hope that BlueCove will give me some insight as to what exactly the BlueMesh interface should expect and contain, so that any interfaces can be written easily.

This task, as large as it is, is one of my greater priorities, for two reasons.
1) It will give BlueMesh greater compatibility and intercommunication
2) It will allow for testing with the library itself to be done one any one platform, and it can be a platform of choice. The Android SDK is nice enough, but doesn't allow for easy debugging. If this interface is successfully written, then BlueMesh can be tested, and eventually operated, between any two Bluetooth-enabled devices.

Over the summer

Hey guys,

I just wanted to write a quick post about what will be going on with BlueMesh this summer.  Sean will be working on the project with RCOS at RPI and he has a lot of really awesome things that he plans to do.  I will be working up by Boston this summer, but I will still try to help out as much as possible.

Some of the changes we hope to implement are as follows:

1)  Port BlueMesh to Java.  Currently BlueMesh only works on Android devices, we plan to port it to Java so it will run on PCs as well.  This will make development much easier and quicker.  Once we have a working version in Java it should be quick and painless to port it back to Android.

2)  Implement message chunking.  Message chunking will allow us to determine the optimum maximum size of a message and allow us to chunk messages into this maximum size in order to allow for maximum throughput.

3)  Implement routing algorithm.  This will allow for point to point communication rather than flooding the network with every write.

There are other changes that are also in speculation right now in addition to these three.  I'm sure Sean will be updating us with his progress often and I look forward to seeing BlueMesh progress.

-Jerry

So close to our first release!

Currently we are one bug fix away from our first release of BlueMesh!

This week I added in an argument to the BlueMeshService constructor so that you can specify a UUID for your program.  This is important because you probably don't want your BlueMesh program to interact with other BlueMesh programs.

This is how you can call the constructor now:
bms = new BlueMeshService(UUID.fromString("fa87c0d0-afac-11de-8a39-0800200c9a66"));



A UUID is specified by hex digits in the following format 8-4-4-4-12.  The UUID can also be used to enable or disable backwards compatibility of your app!  If you would like a new version of your app to be able to talk to an older one, simply do not change the UUID between versions, however if your network protocol changes between versions you can specify a new UUID so that a new version will not communicate with an older version.

The bug we are still trying to fix involves not properly detecting a disconnection and deleting information about that device so that a re-connection will be attempted and successfully completed.  I hope we will have this fixed within the next few weeks and we will try to keep you updated on what we think might be causing it.

WebViewTest Bug fixes

This weekend I fixed a minor bug in WebViewTest (can be found at http://scrambledeggs.myrpi.org/APKs/WebViewTest.apk): The app no longer crashes on start if Bluetooth is not enabled.  I also added more comments to the source so it will be easier to follow.

Please try out the tutorial and try to make your own app using BlueMesh!

How to use BlueMesh Tutorial

This post is a basic tutorial on how to use BlueMesh in your own android project.  Source code for this tutorial was taken from WebViewHost and WebViewTest.

To begin, you can consider the BlueMeshService object both a device for input and output.  This object provides functionality for both reading data from all devices on the BlueMesh network and writing data to all devices on the BlueMesh network.

As a prerequisite to using BlueMesh, a device should enable Bluetooth and pair with other devices.  It is not necessary to be paired with all devices that are going to be on the network, but there should be a path from every device to every other device via Bluetooth pairs.

The first thing that needs to be done when using BlueMesh is create a BlueMeshService object.
try{ bms = new BlueMeshService(); } catch(NullPointerException e){ Log.e(TAG, "Bluetooth not enabeled"); return; }

It is important to note that the BlueMeshService() constructor throws a NullPointerException if Bluetooth is not enabled.  If this happens it means that the constructor failed and you should not proceed, rather you should either end the program, or attempt to enable Bluetooth and try again.

If the constructor completes successfully, it is then time to call launch().  launch begins the Bluetooth communications (listening for other devices running the same app to connect to) and allows you to use the IO functions.
bms.launch();

Now that BlueMesh is running it is time to use the IO functions.  Remember that the UI thread must complete in order to render any graphical display, so it is recommended that BlueMesh IO is preformed in a separate thread.

The following code block shows how to set up a button to send data over BlueMesh.  The write(byte[]) function takes one argument, a byte array, and sends it to all devices on the network.  In this example slides is an ArrayList of Strings.
//button listener send final Button buttonSend = (Button) findViewById(R.id.btnSend); buttonSend.setOnClickListener(new View.OnClickListener() { public void onClick(View v) { if( bluetoothWorking ){ bms.write(slides.get(currentSlide).getBytes()); } } });

In order to read data, use the byte[] pull() function.  This function will return a byte array containing a received message on success and null if there is no message to receive.  This call is non-blocking and will return immediately, please note that it is not recommended that this function be called instantly over and over again in a read loop without a small sleep between attempts.

The following code block shows how to create a read thread the polls the BlueMeshService object for incoming messages.  In this example, the read thread passes messages to the UI thread via Handler mHandler.
private final Handler mHandler = new Handler(){ @Override public void handleMessage( Message msg ){ byte[] byteMessage = (byte[]) msg.obj; String stringMessage = byteMessage.toString(); //Here you can do UI with the message } }; private class ReadThread extends Thread { public void run(){ Looper.myLooper(); Looper.prepare(); while (true){ if( this.isInterrupted()){ Log.d(TAG, "readThread interrupted"); return; } byte bytes[] = null; bytes = bms.pull(); if( bytes == null){ //Sleep if nothing is received to avoid //pounding bms try { sleep(100); } catch (InterruptedException e) { Log.e(TAG, "sleep() failed", e); } } else{ mHandler.obtainMessage (0, bytes.length, -1, bytes) .sendToTarget(); //Here you could process the message //and send a response } } } }

Now that your program can read and write over BlueMesh the only thing that remains is shutting down communications.  This requires a simple call to disconnect() which can be run as the program shuts down.
@Override public void onDestroy(){ super.onDestroy(); readThread.interrupt(); bms.disconnect(); }

Hopefully you enjoyed this simple tutorial on BlueMesh and will be able to develop your own apps.  If you have any questions please email me at schnej7@rpi.edu.

Slideshow Presentations over BlueMesh

Our new test app works with BlueMesh now!  There are two new apps (that work together) developed for BlueMesh that are now in the repository in the WebView branch in the directory "WebViewTest" (the audience app) and "WebViewHost" (the presenter app).

WebViewHost:

The presenter app is fairly simple.  It simply takes strings consisting of html pages and sends them over BlueMesh when the "send" button is pushed.

WebViewTest:

The client app is slightly more complicated than the presenter app because the view needs to be updated during run-time as new slides come in.  This means that BlueMesh needs to be run in it's own thread and pass messages to a handler in the UI thread.  It is important to note that a looper must be prepared if BlueMesh is run in a separate thread than the UI thread.

Stay tuned for a more in depth blog post about how this app works and how to use BlueMesh.

Test Metric Redefined

As programming of our test programs goes on, some of our goals have changed.

The "Fastest Bounce" program works through the CLD, intermittently. We seemed to be getting a bounce time of roughly 1 to 2 milliseconds, though this varied greatly. Also, the program only gets through a few bounces before crashing. We believe that this is due to the CLD front-end, so we are currently trying to implement this test with a stripped-down front-end that will avoid tampering with test results.
Also, as a side note, our last entry didn't include that accuracy will also be tested, even though we haven't seen anything to even remotely suggest that accuracy has been an issue.

The "Largest Message" program will be a moot point initially, since BlueMesh has a maximum message size of 1024 bytes. This will be added to the API. The "Fastest Bounce" test will be repeated for max size, however, to try and obtain a max throughput. As a later goal, we may want to try editing this maximum, but that would require serious code rewrites and is being tabled.

Testing Metrics and BlueMesh

We have been working on developing a number of metric test programs to try and find the technical limitations and performance ability of BlueMesh. Hopefully, we'll be able to get some useful and important data concerning performance and limitations for developers.

Right now, the tests we're trying to create and the questions we have are:
- Fastest Bounce : How quickly can BlueMesh send a small message from device A to device B and back? How much does this time change with N intermediate devices?

- Largest Message: What's the largest message that can reliably be sent through BlueMesh? Does this result in a significant slowdown? What's the greatest data throughput we can achieve with BlueMesh, and what affects it?

I'm considering adding a "Proliferation" test, to see how quickly a message can be sent to a large number of devices, but due to a lack of testing devices, this will likely have to wait.

Fastest Bounce has already been written and is on the git's development branch. It has not yet been shown to work, nor has it been run for numbers. Since I need two phones at least to run a test, achieving this has been difficult, but should be accomplished soon.

A New Test App!

Hey Guys!

I've been thinking of new ways to use BlueMesh and I have come up with some great ideas.  I just posted a REALLY EARLY version of what will be a presentation app that uses BlueMesh to distribute slides between android devices.  The idea is that you will have a presentation and the app will be able to distribute additional notes to the audience.

"How will this work?" you might ask...

The slides will be created using HTML in order to make their distribution across BlueMesh fast and light-weight.  Once the slides are distributed, they will be rendered using Android's WebView object.  The viewer will then have the option to move freely in the slides he/she has received, or jump to the newest slide each time it is received.

If you have any other ideas about what this app should do, ideas for other apps using BlueMesh, or ideas for the BlueMesh API, please post comments on this blog, post on the github, or email me at schnej7@rpi.edu

New Snapshot For Your Testing Pleasure

We have a new and improved working snapshot of CLD chat using BlueMesh. The improvements from the last snapshot include:

1. Quit button from menu used to stop BlueMesh.
2. BlueMesh stops correctly.
3. No more annoying <NOTHING> messages to indicate that the service is running.
4. Display also displays the messages that are sent from it, not just messages recieved.
5. CLD now appends the name of the device to the message before sending it off.

Known bugs include:

1. When device A and B are connected and device A disconnects, sometimes device B crashes when it tries to quit.
2. When devices disconnect, they do not reconnect.
3. Messages do not always get received because some unique IDs are not unique.
4. When the device is tilted you forfeit the ability to send messages from the UI.

PLEASE, download and install the .apk and try it out!  You can get it from www.bluemeshproject.com or by scanning this QR-Code.

NOTE: you will need to pair the devices you want to use on the network BEFORE you start the app

API Release, New Wiki

Today, I started a wiki containing information about the BlueMesh project and library. It currently contains a number of links to information, as well as a few pages that help outline the API as it now stands. It can be found at bluemeshproject.wikia.com. In addition, a current API has been released and more information about it will be added to the wiki in the upcoming week. The proper beta isn't out, but the library is in a working condition and documentation is being written.

-Sean

EDIT: The wikia wiki has now been deprecated, and a current API can be found on our Github Wiki.

Implemented Quit() function for CLD and BlueMesh

We have implemented a quit function for BlueMesh. While in the application (using Commandline Like Display), hit the "options" button and then a quit option will appear. This calls a quit function in the CLD service, which in turn calls a disconnect() function from blueMeshService. From here, the threads are interrupted and the sockets are closed.

We had a bit of trouble with this at first. The first issue was with the clientThread quitting properly. Before having the thread interrupted, all the sockets opened must be closed. Also, IOExceptions cause a bit of trouble with the thread.interrupt() flag, so we used a boolean. Second, CLDMessage uses a blocking call to get a line from the Android Keyboard. since CLDMessage.getLine() was being called from a thread in the blueMeshDisplay example service, we implemented a function that calls alertAll() from within the CLDMessage class.


We hope to have an official Beta release very soon.

IT WORKS IT WORKS IT WORKS!!!!!!!

Today at 2:30 p.m. we had our first successful test of BlueMesh.

Currently everything is implimented and working except for stop.  On our test application you can type "quit" to stop BlueMesh, but the ClientThread continues to run.  Once this bug is fixed I think we will be ready for our first Beta release.

Stay posted for our release and the launch of our wiki documenting our API.

Also I will post the test aplication's APK on the website so you can download it and try it out!

New Member, Documentation, and Development

Hello, All!

My name is Sean, and I'm a new addition to the BlueMesh Project. I have gotten more or less set up, and I plan to spend the next week or so working on the documentation in the project. My goal is to have a clearer and more explanatory API as well as supplying written instructions for various tasks both internally and externally.

This has a twofold purpose. The first, and most important in my mind, is that it will make the library much easier to read, understand, and implement to any developer using it. The second is that it will make development itself easier, as we will have a documentation to fall back on.

Eventually, I will be developing applications myself in this library, which I am also looking forward to.

It's working... better

Today Trevor and I did a lot of debugging and fixed a number of bugs:
1) The device doesn't attempt to connect to another device that it is already connected to which resulted in a crash
2) The example device also converts bytes to strings properly now

The program is currently displaying the following behavior:

1) Startup (consistently)
2) Cycle through devices and attempt to connect (consistently)
3) Connect to device in the same area running the same program (not consistently)
4) Once connected send bytes (consistently)
5) Read bytes that were sent to this device (consistently)
6) PROBLEM: Accept messages and re-route messages that have already been received (consistently)
7) PROBLEM: Messages received have LOTS of excess white space (consistently)

When one device sends data "hi"
The other device receives data that says "<excess white space>hi<excess white space>"

Help us debug!

If you're really excited about BlueMesh, here's how you can help up debug.

What you need:

• Eclipse + Android SDK + Eclipse Android plugin
• 2+ Android devices, OS-2.1 or newer
• At least 1 micro USB cable to connect phone to computer

What you need to do:

If you do not want to compile the code, I will post a compiled .apk and put it on the BlueMesh website (www.bluemeshproject.com) which you can download and run on your devices.  If you do this, then skip directly to step two.

Step 1: Because BlueMesh is a Library, we use CLD (https://github.com/schnej7/Android_CommandlineLikeDisplay) to test BlueMesh.  The current version of the repository has an example program that uses BlueMesh to Launch the service and read and write data to the other devices.  You can download the source for both CLD and BlueMesh.  You will need to set BlueMesh as an Android library and link to it from CLD in order to compile it.

Step 2: Once you have it all compiled, you can run the .apk on your device through Eclipse which will give you a debug log.  Feel free to submit your bug fixes through github or simply send your debug log and a brief description of of the behavior of the program to schnej7@rpi.edu.

I encourage anyone who is interested to help out debugging, we will be able to debug much quicker the more logs we get.  Thank you all in advance for your help!

Bluemesh Testing

Today me and Jerry managed to compile an instance of a very simple text debugger app (using commandline like display) and the bluemesh library. However, we have run into a few problems. Currently, bluemesh does manage to connect devices both running the application, however, not entirely consistently. Also, data did get sent, although not received correctly. There are also some some socket and thread management issues that cause errors. We hope to have most of these errors remedied by next week.

SO MUCH PROGRESS!

Since our last big update on Sunday the BlueMesh team has gotten a LOT of work done.  Today we finished the complete reworking of the project.  All of the functions that we will need for the most basic uses of BlueMesh are now implemented.  By tomorrow we hope to have everything tested and have a sample app demonstrating how BlueMesh works.  Our implementation is still yet to be tested, but it looks promising.

I will write another blog post as soon as we test our project with the results, wish us luck!

Client Thread

The client thread curently has:
** constructor (Handler mHandler, BluetoothAdapter mAdapter,
RouterObject mRouter )
** public void run()

The constructor takes the three arguments and sets the values to private variables.

Run is as follows:
the thread continuously runs until an interrupt is given, and first gets a list of paired devices.
For each paired device, it attempts to create a client socket. If that's successful, it then attempts to connect to a server socket. If that is successful, the connected socket is then passed to the Router Object to be handled.

This week at BlueMesh

Today I spent a few hours with Trevor Zettersten and Zachary Clapper redesigning and restructuring BlueMesh.  It turns out that I was doing some things wrong... really wrong.

We will spend this week setting up the skeleton for BlueMesh and trying to implement most of the functionality. Compared to the former design of BlueMesh, the current design is much more elegant and simple.

I expect that we should have a significant amount of work done by the end of this week.  We will also be giving  an RCOS talk this Friday explaining more details about our new structure and the BlueMesh API.

BlueMesh: API's, and You.

We have now sketched out a general procedure, and planned several API's to be implemented, for BlueMesh developers.

the initial phase in BlueMesh programs will be creating a BlueMesh object. Programmers will be required to choose between two different types of networks: Static and Dynamic. Static Networks lock in everyone into the network upon creation and will throw an error if anyone joins or leaves afterward. An example program that woulhd use this is a poker game. Dynamic networks handle adds and joins on the fly, and could be used for a chat room.

(The following describes the procedures required for using a dynamic network. Static network procedures will be developed later)

Next, a password, along with other options, will need to be set via a config API. Finally, A "Launch Service" API will be called, that will handle the sending and receiving of data. Both sending and receiving will be asynchronous, however data receiving will be slightly more involved. Once data is received, it will be pushed onto a queue for processing. Data will be pulled one at a time, and passed into a "handling" function that the programmer will write. Finally, a disconnect API will need to be called to handle the exiting of the application.

List of API's to be Implemented:
*Constructor (Dynamic and Static Networks will be inherited BlueMesh Classes)
*Config (Will take in password and other various options for network)
*Launch Service (Handles starting threads and managing connections)
*Send Data (Allows the sending of packets)
*Pull Data (Attempts to grab data off of processing queue, will return null if queue is
empty)
*Disconnect (Handles exiting of application, a destructor)