-- Moved by moderator to Emcomm Applications - General forum --
Detailed information and installation instructions can be found here:
http://www.trevorsbench.com/meshchat-messaging-for-mesh-networks/
Hi I’m Trevor K7FPV.
We have a mesh network running in Layton, UT with around 12 nodes. We mainly setup and use the mesh for emergency communications. We have been using Team Talk running on a Raspberry Pi off my node to communicate. I’ve never liked this solution since it requires my node to be online as a single point of failure, and Team Talk is not the easiest thing to use, and does not work on mobile devices.
We tested Ham Chat, but again same problem. If that nodes goes down, your messages go with it, or you have to all login to a bunch of nodes. Great app for what it does.
I wrote a web app called meshchat that runs on the node it self. It has a modern responsive / ajax web interface. The concept is you can login to any node running meshchat and see the message database and send messages. The message database is stored in RAM and a smaller version persisted to FLASH. There is a daemon that runs all the time on the node and requests the message/user database from every node on the mesh. If it finds a new message it adds it to its own copy of the database. This way every node always has a full copy, fully distributed, fully redundant and p2p. No single point of failure or a server. It also keeps track of which users are currently logged into which node, and which node the message originated from. When you install on a new node, it will instantly get a full copy of the message database from another node. Depending on the speed and size of your mesh it can take a few seconds to a few minutes for new messages to fully propagate.
We have been running this on our mesh for a few weeks and it seems to work well but should be considered alpha software at this point. I invite any one else to try it out and submit bugs to me. Right now the app just does text messages. I’m making some progress using webrtc to add p2p video and file transfer, but it is tricky to do without a server involved for ICE / STUN setup. Anyone who is familiar with webrtc is invited to help ;).
Right now there are some prerequisites to running this:
* Must be installed on Ubiquiti hardware - may do linksys support at some point
* You have to reboot your node after installing the package for the daemon to start - trying to figure out a problem with it starting after package install
* We have tested only on 3.1.0, but it may work on other versions I don’t know
* You must have the correct time set on your node - NTP is a great way to do this. We used the nodes times in UTC and in javascript convert it to that users timezone in the browser. May change this to use the time from the browser instead since NTP may not be available.
* You must have the wget-nossl package installed - this is because the busy box wget does not support connection timeouts and a unreliable node will stall the daemon forever.
You can see the code here: https://github.com/tpaskett/meshchat
You can download a wget-nossl package here (install this first): https://www.dropbox.com/s/skhmaxukad5p59y/wget-nossl_1.13.4-1_ar71xx.ipk?dl=0
You can download the package here: https://www.dropbox.com/s/4jkrntvby3sx467/meshchat_0.1_all.ipk?dl=0
Possible features in an update:
Auto update all nodes on the mesh after updating 1 node P2P file transfer P2P video conferencing
We have been running this on BBHN and recently got some extra radios to test AREDN and it seems to work fine on AREDN also.
Thanks to Bill N7IE and Dave KD7DHO for their work on our mesh and for testing. Feedback is welcome.
Thanks for a very interesting contribution. One question... how hard do you think it would be to port this to a Linux SBC, like the R-Pi? Or maybe, in other words, how tightly is this tied to openWRT?
For others who may follow... this is accessed by http://<your_node_name>:8080/meshchat
And, I can confirm it works on aredn 3.15.1.0b04
This would be fairly easy to do. The only mesh specific stuff is getting the name of the node and getting the list of nodes to poll. If you downloaded the scripts from github and put them under apache then you would just need to change a couple things. /usr/local/bin/meshchatsync you would change the line at the top:
Replace NOCALL with the name you want the node to be.
if ($node eq 'NOCALL') { $node_list = ['K7FPV', 'K7FPV-east']; #$node_list = ['172.16.50.1']; }Change that code to replace NOCALL with the new name, and $node_list needs to have the hostnames of nodes on the mesh to poll. In the next version I'll make is use `hostname` if nvram_get is not available.
That is pretty much what I thought. Getting the node list would be easy with a curl request to olsrd on port 1978
Trevor... Ok, again thanks for the nicely done code. After a brief test I have a couple of comments and then a question.
Comments: when a user logs out of a node, it takes about 5 minutes before they are removed from the user list on other nodes. The screen looks nice. But, it also uses a lot of screen space. In practice, Since the intended application seems to be for emergency use I think it would be better to provide as much message history as possible, possibly in a scrolling window. This could be accomplished by reducing type sizes and leading and gtrai9ning space around each message. Possibly you could allow for these to be set in a config file.
Question: As each node polls for updates, does it poll all current mesh nodes, or does it optimize and only try nodes found to be running meshchat?
wb6tae - Richard
Right now it will drop it out of the active list when their last poll of their node is 5 mins old. That could be configurable or something. There is definitely more work to be done in CSS to make the font sizes and such render well on multiple screen sizes. It will show all messages in descending timestamp order and you can scroll the whole page.
It polls all nodes, and if a node does not have meshchat that node just returns a 404 and it moves on to the next node.
Thanks for the feedback.
As to the time-out period. I can see this two ways. It is nice to see who has recently been on (and might rejoin) , but, it is also nice to know as soon as someone is dropped. How about this: gray out the user name immediately, and then drop it after 5 minutes.
As to polling. I see that meshchatsync uses around 7% cpu time on a NanoStation M2 while polling a network with only 11 nodes (only 2 running meshchat). I would assume that many nodes in a network would not ever have a meshchat instance (co-located - dtd-linked nodes, back-bone links, etc.) So, a lot of time is bound to be spent polling nodes that will never respond. However, you also don't want to miss a new meshchat instance that comes up. So, how about this. Tag nodes that return a 404 error and skip them when polling. But, once every 5 minutes or so, poll the full list again. That should be fairly simple. However, for immediate discovery of new nodes, you might consider having a node send out a broadcast of some type at to announce its presence. If you did that, you would only have to poll the full mesh at startup. In this manner a crashed/rebooted node would be quickly deleted (404 error) and new/rebooted nodes added as they came up.
EDIT: Actually, if you can discover new nodes, then non-responsive nodes could just be dropped from the node list instead of tagging them.
Yeah some good ideas. There is some un-neccessary overhead right now with file size checking using `ls -l XXX` vs stat() which I have fixed. I thought stat() was not available on mini perl, somewhere I read that, but looks like it is. The whole thing needs a performance review. I'll take a look at your suggestions once I get the file sharing stuff I'm working on done. We share spreadsheets during our emergency exercises to report on each home what the status is, so we need a way to do that without a server. I like the grey out idea, will do that too.
Just a note, the nodes actually run full perl not microperl.
I hit a number of flaws in microperl latest versions when I ported from Linksys (various really small code items that ran in old micro perl did not run in new microperl). At the time I was under deadlines so full perl went in as it was much more stable and hasn't been pulled out (especially since we're looking at moving to LUCI eventually for the GUI spending time to fix micro perl would be inefficient)
Trevor:
I hacked in a quick change to track the remote node response and avoid checking nodes that returned errors. There is a periodic retry-all based on a counter. If you'd like to see the code, let me know your email address and I'd be glad to send it your way.
Richard - wb6tae
Here is a teeny contribution, mostly to save you some typing... Also wondering if you thought about gziping the message files for sending? I was just wondering what the traffic impact would be if 10 nodes were all exchangiung the message db on a mesh with some slow links.
$cur_size = get_file_size("/tmp/remote_messages");
sub get_file_size() { local ($fname) = @_; ($dev, $ino, $mode, $nlink, $uid, $gid, $rdev, $size, $atime, $mtime, $ctime, $blksize, $blocks) = stat($fname); }BTW, I tried
$size = stat("messages")->size;but it didn't test any faster and took a hit loading File::stat
Thx for the code. Email is snoopytjp a gmail.com
This is not a replacement for what teamtalk dose. If your only using Teamtalk for text chats then Ya. No Video/ voice chat or desktop share.
Im a wondering why I every node listed, needs to get called, or dose it only do that when some one is logged in?
Your right it does not do everything team talk does, but will let you communicate when the node that has your team talk server is down.
A message originates on the node the user is logged into when they send it and is added to it's message db. Then the other nodes will pull it's message db and add any new messages to it's own copy of the db. They need to call each other, since there is no central server.
Thats good way to deal with the messages! As a side note TDRS works in a similar way, store and forward data in a chronological data base, bad transmissions can be reconstructed from the other databases of transmissions.
http://bearware.dk/?p=279
Suggestion:
It would be good to automatically add it as a published service (like we do on the AREDN version of hamchat).
D.
Yeah great idea I'll add that in the next version.
K7FPV, I noticed that the self-node captures some information in the flash memory. As I recall, flash technology has limits on the # of writes--order of 100,000--before memory circuits start to fail. Is this of concern for node owners? How often would we expect flash writes to occur?
Thinking out loud, if there's a flash write for every message sent and I send 10 messages a day, it would take 28 years before we would expect to start seeing flash memory errors. As a node owner I wouldn't be too concerned, I won't have this same device operational for 28 years :) if I'm still alive. But is this logic correct for the application?
Joe AE6XE
Yeah in the next version I disabled the write to flash, it will kill it eventually. Maybe that could be a config option later. I think I will make a raspberry pi package of meshchat. Then your raspberry pi can persist the message db for you where ever you want, vs using flash on the nodes. Then you can chat from the pi also. You could just use multiple pi's in your mesh vs the nodes also, or a mix however you like.