Is it possible to set up the Android Bluetooth Chat sample app to connect more than one person at a time, and have a mini chat room? What would that entail?
tl;dr version: Bluetooth sucks for this, don't use it, use wifi instead, probably backed by a web backend.
I have investigated this issue thoroughly throughout the years in the interests of a social wireless network research project. My general advice is: it doesn't work with more than two / three people. Bluetooth just isn't designed with wireless peer to peer networks in mind.
In general, it seems that the cheap Bluetooth controllers included on Android devices (especially HTC's devices, iirc) don't really handle any more than two or three connections at a time. I'm unsure if this is a hardware or firmware problem, but I can recount some basic anecdotes. I was working to implement this idea at the SDK level (i.e., without firmware modifications) around the beginning of 2011, and was able to get a peer to get two additional connections (i.e., three devices, each connecting to the other two) to work for a period of a few minutes to an hour before the connections would suddenly die and the socket would become unusable, requiring reconnection. Unfortunately, 20 minutes was an upper bound, and generally it was impossible to get connections to more than one other device at all reliably.
The goal of the project was to support multiple people interacting with each other silently in the background, but this never materialized, instead we ditched Bluetooth and went with wifi instead, which worked much much better. In the abstract, I think people view Bluetooth as a possible medium for reliable peer to peer communication, but it wasn't really designed that way: it's more of a medium used for short range communication between small devices (think headsets).
Be aware that if you want to do this, the maximum number of devices to which you can connect is fixed, because as per the Bluetooth spec, a piconet supports a maximum of seven devices. (See the wikipedia article.)
The required change is simple: you use a different UUID for each device. This can be implemented a number of ways, using an out of band exchange mechanism, or simple scheme where you assign UUIDs in an increasing fashion and when connecting to the network, try each in succession.
Here are some relevant Google groups threads:
Bluetooth peer to peer networks
Multiple connections on Android Bluetooth
I remember posting a more elaborate one detailing how to do this (with code) that I might dig up as well.., if I can find it. It should be from late 2010 or early 2011.
So the answer is, in the abstract, yes, you can try to do this, by using multiple UUIDs (after you use one, that's it, and you have to try another using some assignment protocol). However, in practice, after a lot of trial and error, this doesn't really work for what you probably want to use it for, and it's a lot better to go with an internet backend instead. By the way, this is also good for another reason, most users don't really like to turn on their Bluetooth for fear of their battery being drained..
Leaving this here, in case it helps someone else.
I was able to make my custom chat room following official bluetooth tutorial and modifying it a little.
Unfortunately, I cannot provide most of my code, but main idea is:
Every device is acts both as server and as a client. When Chat is started, device starts its server thread. Server thread is the same as official but doesn't ends when accept connection. It just keep listening.
Client thread is identical as in tutorial.
Both server and client thread manages connection same. I created separated threads for accepting messages following this tutorial and one for sending them.
private void manageConnectedSocket(BluetoothSocket socket) {
//create thread responsible for sending messages.
SendingThread w = new SendingThread(socket);
MainActivity.addSendingThread(w);
//Creates listener for messages to accept.
MainActivity.addListener(socket);
}
Now in main activity always when user click send button, for each worker (sending thread) send message to remote device. Listening is running asynchronously.
IMPORTANT:
You need to handle exceptions when message send fails and remove sending and recieving thread for device when you detect it is disconected. In my case I used well known UUID "00001101-0000-1000-8000-00805f9b34fb". For every device.
You need to wait 3 second between atempts to connect as client because some devices has weak bluetooth hardware and it is refusing connect as client.
Bt connection is supporting up to 7 -10 connections. So you will be limited in that range. I think it is designed for extensions of main device and not for random comunication
Source: search "bluetooth programming" on google
Related
I am working on a project where I need to transfer data between android and raspberry pi via Bluetooth. However, I am new to this and I don't have deep understanding on what happens when two devices are paired. Based on assumption that the two devices of interest are already paired, where would the starting point be for programming for such task? I've been reading on BluetoothSocket, but I am still unsure of where to start. Can anyone help me please?
Thank you so much in advance!
I have been looking into this same issue, here is the reading I found on my end. I was looking to specifically code in python so that's the angle of the first one, the second is C++, but has a really thorough intro.
https://people.csail.mit.edu/albert/bluez-intro/index.html
and this one is really good too, the intro isnt too dense:
http://beej.us/guide/bgnet/output/html/multipage/index.html
The specific parts to look at involve the planning aspect. The intro of the beej programming guide shows specifically what sockets are and how they fit in a network sense. This means streaming sockets and datagram sockets. It also shows which of the sockets are used and which are availible. Chapters 1 through 3 gave me a solid enough reading basis to use the second document to determine a few things.
Chapter 2 of the MIT document goes into specific detail about each of the steps that must occur at a structural level including L2CAP + UDT, RCOMM, and whatever the stream one was. From reading these I was able to determine that the network I wanted to use was an L2CAP. I hope these help point you in the right direction though as far as what network you want to setup and what language you want to program in.
I've been working on the same task little while ago. The point is, that in order to start sending and receiving data you have to establish connection first. There is two side- device which connects (creates socket) and the other receiving connection (bluetooth server socket), giving out connection once connection is complete. After connection is established, you should stop receiving incoming connection or attempting establishing any connections.
From implementation perspective, you should implement few threads for managing all those stages - connection thread, accept thread, communucation thread. There is a great example from Google: https://github.com/googlesamples/android-BluetoothChat . It uses that technic. The only drawback is that it uses Handler (Android feature, allowing thereads to communicate) for informing user about Bluetooth events. I modified it a bit by introducing another thread, receiving status updates and calling methods from callback interface, feel free to use code from project: https://github.com/AlexShutov/LEDLights.
Currently I have a question about using Android Wifi, Bluetooth APIs together.
(Please be noted that it's a problem on app development, not for a normal user guide)
I have a trouble when search device' services via Wifi at the same time with searching device via Bluetooth.
For more info:
On wifi search, I use Bonjour protocol (an Apple's implement of Zeroconf which can help locating services that local network devices offer). The Java implement that I use is jmdns. During the search session, I create a MulticastLock in order to receive multicast packages of Bonjour.
On bluetooth search, I just use BluetoothAdapter together with BroadcastReceiver to get bluetooth device info.
Problem happens to the search result, whenever two search sessions above are executed at the same time, mysearch result on Bonjour (Wifi) search has never get enough like it does when only it is executed.
Ex: Bonjour search just gets 1 instead of 2 device' services when search together with Bluetooth. Bluetooth search result is always enough, however.
This is tried many times and I surely confirm that there is nothing related to network' strength problems.
Has anyone met this problem yet?
Even if your situation is about using Wifi together with Bluetooth, any experiences or guests are very helpful to me!
Khoi.
I am doing pretty much the same stuff you are doing.
My experience differs in that:
I do not use Bluetooth discovery, as I know what device I want to connect to. I just initiate a client connection.
I use Asynctasks for background operations. What are you using?
Two possible issues:
Multiple Asynctasks not executing in parallel due to Android faulty implementation. I have had a similar bug after setting my Android API target to the latest SDK (as it is best practice). Now, after API13, Android Asynctask implementation changed and tasks are NO LONGER executed in parallel (so my wifi thread never started for example, if bluetooth thread was running!!!). The fix is to put a couple of lines of code to make the default executor parallel again, or to just use API11 or lower as target version. See this thread for details.
OverTheAir interference between the 2. Bluetooth discovery is, to my knowledge, the most expensive operation you could do on Bluetooth. So that 2.4GHz multi-purpose chip may be swamped over the air. Internally it has coexistence between WiFi and BT. Remember the WiFi and Bluetooth channels over the 2.4GHz overlap. So what I am saying doing discovery over the same main frequency at the same time might not work that great. You should investigate that...
I'm developing an none market appliction which run on 20-30 android devices (target specific to tablets with android honeycomb / ICS OS) maintaining connection over local WIFI network for a 1-2 hours period of time, and need to exchange data (simple objects representing commands) between them.
most of the time one specific tablet behave like a server which sending the commands, and the other devices like clients which receives the commands, but the "clients" also sending commands to the "server" sometimes.
as solution to this communication demand - I'm using for a while an open source
library which encapsulates TCP client/server protocol, called - Kryonet.
I found it very easy to use, and basically doing the job, although it sometimes "unstable" - a lot of disconnections accrues. I can't afford this disconnections, it's dammege the whole flow and use-case, causing the client's to lose commands.
I'm doing some recovery logic which re-connect the clients and send them what they have missed, but it's not good enough for the use-case.
recently I've heard about multicast broadcast protocol, and found even an open source library calls - JGroups which implement this protocol optimally, and expose easy and simple to use interface. still didn't tried it, but got advice from someone who knows, saying it should be better the the TCP client/server for my purpose.
what is the best approach I should use for implement the behavior I described ? (not necessarily one of the two I suggested)
TIA
Although JGroups has promise as a better solution for your situation, you may want to experiment a bit more to determine why the disconnects are happening. Since your clients and server are all tablets, there are a few other causes that are unrelated:
1) If the connections are not being maintained in a Service then they will be extremely unreliable by default. (See this question about singletons being destroyed in Android)
2) If the sockets have not been set to 'keepalive' then they will time out after an arbitrary number of seconds.
3) The devices you are using may shut down some persistent connections when they go to sleep.
4) The tablets may be exiting WiFi range, and switching over to a mobile network.
Try the network portion of your code on a number of desktop machines to determine if the problem is with Kryonet or your code, or if the problem is in running it on Android.
I have two Android devices. One is acting as a server and the other as a client. The client connects to the server and requests a file - this is done in one thread on the client and one thread on the server so that both can continue doing what they want.
The client then attempts to connect to the server again to request another file. Right now I am getting a java.io.IOException: Device or resource busy when attempting to connect (socket.connect()). Is it because Bluetooth (on Android) only allows one channel between two devices? (if it were another device it would work but if it is the same it doesn't ?) Note that both attempts are made with the same service name and UUID.
Even if the error is specific to my code, I would like to know if this is the case or not.
System: android 2.2.1 communicating with the bluecove bluetooth library.
Definitely not with the same UUID(universally UNIQUE Identifier).
Reference for that was taken from here
Maybe with more than one. You can connect multiple devices in the Server/Client style, you can try to set one of the devices as a server and start several clients on the other. My first guess would be to start several client threads, but you might have to find a way to change the MAC address for each of them.
Here you can find another discussion about how to change your mac address, but only works in rooted devices. I can't find anything else for non rooted ones. No idea on how to do this programmatically but it might give you a start.
Here there is a discussion about connecting several clients at the same time in a server. I got there from this question. ( I think this might be your closest shot)
Here you have a discussion about peer-to-peer networks.
AFAIK, multiple connectivity is not possible in case of Bluetooth Connection. Bluetooth is Connectivity API is by default Synchronized so only one connection at a time is possible. So you can not perform multiple connections.
However it can be possible in another way like making one connection , performing 2 seconds operation on it and then creating another connection and performing 2 seconds operations like in normal multitasking operating system happens.
can anybody confirm what are the currently allowed methods for peer-to-peer communications within the Android framework? I need to transfer json strings and I'm currently using SMS which works ok but the problem is that the data also ends up as lots of text messages. I've read Reto Meier's first edition of Professional Android Application Development where he says that the data transfer options were not implemented due to security concerns.
Has this changed at all and how would you do peer-to-peer transfer of data?
Have you looked at Qualcomm's AllJoyn library? It is designed to work over Bluetooth or wifi, so may fit, though if you're connecting over 3G or wider range networks it won't work.
Given the variation and reliability of networks between two remote devices not on the same network, I'd question whether peer-to-peer is the best solution, and would venture to suggest considering using an application server in between, so you could then use Cloud to Device Messaging [deprecated] (perhaps in tandem with Google App Engine). i.e. to send a message the sender passes it to the server, and the server then passes it on to the recipient.
In theory all devices on the net have a unique IP address and can talk to each other, but it's rarely that simple as routers/firewalls are configured differently so you'd need to pay great attention to the ports you use, especially considering many inbound ports are blocked by default for security reasons.
You can simply use UDP/TCP sockets. In a separate thread you set up the server-side listener socket and that's it. Of course your application has to be started first (or should run in the background all the time). Here's an example:
http://thinkandroid.wordpress.com/2010/03/27/incorporating-socket-programming-into-your-applications/
If you also need peer discovery that will make the thing more difficult.
You should also take a look at peerdroid, an open source project available here. I've been looking in to peer communication options from the point of view of having a collection of federated devices (pre-paired, if you like, similar to Bluetooth pairing); this library looks like it may give you the foundation for what you are trying to do.
If you are on your own network (for example a home or office WiFi) then you should be able to query for other connected devices. If the network you are on is not under your control (the mobile network or a public wifi) then the network will have been configured to isolate each device from everything else. In this case you will have no choice but to put a server up to act as the man in the middle. That brings its own architectural compromises - every device has to regularly poll the server or keep a connection open - unless you use Google App Engine which supports push notifications over Google's own infrastructure.
Thanks for your answer ldx but I would need peer discovery as you indicated. Some further research appears to indicate XMPP as a suitable technology and there are now some services on offer, although these appear to be aimed at 'server' to client notifications. There is a good discussion here on XMPP and some more here although it would appear that there are still some issues to deal with such as polling v push, long-running open http connections and battery life. Xtify looks promising, especially their web service. I hope this provides suitable information to others looking at the topic of peer-to-peer data communication.