I'm developing a piece of software which consists on mobile clients and a machine acting like a server. This is for a highly trusted environment (not public), so I don't care much about security.
I want the clients to be allowed to perform a certain action only if they are, say, 2 meters from the server.
As the client is actually an HTML5 app, it would be better if the server perform the check, not the clients (maybe the clients can send its position to the server and then he performs the check), but if it cannot be done, it doesn't matter.
I have run out of ideas about how this can be done. I have thought about bluetooth and geolocation, but can that detect if the client is at least 5 meters nearby?
Is this even remotely possible?
You can use sound waves to do this. These links might help you get started:
How to estimate distance between two android devices? (bluetooth preferred)
http://www.ehow.com/how_6075947_measure-two-locations-using-sound.html
http://iqtainment.wordpress.com/acoustic-ruler/
Related
This question follows on from Unity3D -- Send message to other mobile phones in the same vicinity
However, I made mistake of restricting to Unity3D.
So I would like to re-ask the question without that constraint.
Let us say we have 20 mobile phone users in a cave (so no Wi-Fi networks / isGPS)
One user hits a button, and every other user's screen flashes, (within a few milliseconds)
How to accomplish this?
What if everyone is using an iPhone?
What if there is a mix of iPhone and android users?
Finally, is there any solution that would cover a wider range of phones?
You should have some network so that mobiles can share some data. Bluetooth can have maximum of 10 m distance coverage (depends upon devices though). Since, all mobile are running same app they should be linked to a network and communicate. Please Check:
http://developer.android.com/samples/BluetoothLeGatt/index.html
You can create one device as server and communicate among other devices.
https://github.com/polyclef/BluetoothChatMulti
If you have installed the app on all of the devices then in all probability yes, if the device supports push (pretty much any smartphone) then you can use the push service to synchronize the devices based on geofencing (ie, 10m from my location), there are some other discovery routes you could try to (without using the B word) pinging other devices
the app would need to be able to provide some sort of server service if it was to create its own private network based on the IP addresses of the devices it found nearby, as those devices would have to connect to that phone acting as a server. the network interface shouldn't be important, but connecting the satellite devices to the server should be. You could try doing it based on which device can provide data services, aka hotspot. You can easily connect devices to networks programmatically.
at that point your faced with the classic client server problem. There is going to be a huge amount of work to get devices configured, network creation, client server infrastructure if it has to be done without data, packet optimization. Very expensive and very high risk depending on how many restrictions there are.
Search for How to make a html5 group chat and then build on that example.
Possibly send commands to the chat delimited by a / character where a javascript could then execute the command.
Good Luck with your design.
Danny117
I was thinking of using multiple Android devices (e.g. Nexus 7 tablets) to build a photo / video wall and I'm wondering a) whether it is possible and b) how to synchronize the display of all these devices. Google showed off its Chrome racer experiment so clearly it is possible to synchronize displays across many devices.
So here are my questions:
what technology should I use to synchronize the displays? Android? Chrome? Please point me to existing code if possible.
what's the minimum lag between devices that could be achieved in such a setup?
can video and sound playback also be started simultaneously on multiple devices (think video wall)?
what kind of architecture should be considered for such a project? Centralized server that sends out commands? Should devices talk to each other?
I'm very curious about suggestions!
EDIT:
blinkendroid is the only app I've found so far that might do the job. Pros? Cons? Alternatives?
Technically the screen isn't shared, the games state is shared and the phones all render the state as they understand it.
Just a bit of background about Chrome Racer. We have a case-study on here, but it doesn't fully cover the question you are asking.
The primary technology used for communication in Racer is WebSockets. WebSockets allow one client to push and receive messages from a server in near-realtime.
Racer starts a session for a game by giving it a unique ID and holds open a Web Socket to the user. Anyone who subsequently joins a game is told to use the Same ID and the server creates a Web Socket to them as well. Now the server knows all the participants.
When a game starts a message is broadcast to all the participants asking them get ready to start, during this phase the server is working out how long it takes to round trip messages to all the clients. It is doing this so that it can work out any latency between devices and thus attempt to compensate for the latency on the slower clients.
Now the server knows about the clients the game can start properly. As the users are playing their game their commands are being pushed to the server over the web socket. The server the relays this message out to all the connected clients (like a satellite does) and it does this same thing for every single user that is connected to the session. This is how the games state is shared.
As each client receives the commands that are broadcast to it from the server it updates its internal representation of the game and renders that to the screen.
And that is about it.
Actually, we wanted to use WebRTC Data Channel because it can reduce the number of hops that data has to make to reach the client. In our solution today a client pings the server and the server relays the message (2 hops), we can reduce the latency by half if we can send it directly to the other user (which is the goal of WebRTC). Unfortunately WebRTC was not ubiquitous enough to deploy this as a solution at the time.
Websockets means web. You don't need the web to sync multiple devices at the same physical place... For video/music syncing, native apps via local offline technologies like Bluetooth or WiFi sounds more reliable.
I'm trying to make an application for android such that I can control my computer mouse by moving on the phone screen. This means it needs to be quick and responsive.
So far I have the websocket server written that listens for movement, which works great when using a laptop's browser as the websocket client. However, I've tried several websocket clients for android, but they're all very slow and unresponsive.
Is it possible to create a websocket connection with android that can deliver real time communication? How? If not, any alternative solutions?
Thanks!
What you are looking for is fastest streamed data, with chance of missing some packets - as they are not mandatory to have persistent state.
So in your case UDP transport protocol would be the best choice. As it offers speed in a price of reliability on data delivery. So you might have messages dropped, but the ones that will be delivered will get there relatively fast (most will be delivered).
As well you need to implement some extrapolation, in order to predict mouse movements if you want to have feeling of being "in same time" on both sides.
Although, clicking - should be delivered reliably, with specific location of click. That way clicks can be properly simulated.
I am developing a turn based two player android game. Is it possible to use one of the user's mobile as server rather than an external server to coordinate the game ?
I do not need much data storage. only 40 fields(text or numbers) to be stored and transmitted (for transmission , one value at a time) while the game is on. after game is over only user's current score is to be stored.
I guess to do any such thing I need to get ip of the mobile. Is it possible ?
You need more than just the IP since the IP is just an endpoint on the Internet and there is no guarantee that it is your device that answers if you talk to that IP. There is usually a local network behind that IP and you can't access devices in there with just the public IP.
The problematic part is establishing a direct connection which is (usually) not possible on the Internet unless you are in control over the Internet connectivity (router etc) and can setup port forwardings / firewall rules / whatever blocks direct connections. If you have no access - for example because you use 3G where the "router" is at your provider's datacenter - you will need at least a server to do things like hole punching.
Also a server used to find other's games (and IPs) would be a good idea.
You can however do all that if both devices are on the same WiFi and they can see each other directly.
I am from Skiller and I think we have exactly what you need.
#zapl is right, if you want your players to connect to your games using 3G or WIFI connection the best solution will be intermediate server that makes it possible to exchange data between the players. Setting up, hosting and scaling such a server may be very expensive and time consuming thing. We provide FREE SDK tools, using which you will be able to set up your turn based two player game in no time. We are handling all the server side maintenance so you could just implement the game logic and fire your game to the market asap.
Download the SDK from www.skiller-games.com and tell me what you think.
If you have any questions write us here or to developers#skiller-games.com
I'm currently working on an android project and I am trying to find the best way to go about setting up communication between two android phones.
One android phone will be docked on a mobile platform e.g. an R/C car. I want this phone to receive simple control signals ("forward", "backward", "left", "right", "gotoCoordinate") sent from another android phone. I also want the docked phone to be able to return status signals.
Preferably I want the communication to happen via GPRS. I'm aware of the difficulties concerning P2P-communications and I'm currently looking into "Android Cloud To Device Messaging." (http://code.google.com/android/c2dm/index.html)
I'd like to hear about your experience with Android C2DM (glad to hear about delay from transmit to receive) and your thoughts on utilizing it in my project. I'd appreciate other suggestions on how to go about this. I'm expecting to have to deal with relatively high latency using this method, but of course preferably lowest possible.
C2DM makes no guarantee about the "delivery or order" of the messages, and it is limited in the number of messages you can send (a high limit, but still a limit). It's not really for low-latency stuff like controlling an RC car. It's better for non-realtime events.
http://code.google.com/android/c2dm/
For lower latency stuff using GPRS you can setup a third party server on your own and have both phones communicate through it. I've done that for several Android apps using straight up TCP sockets and it works reasonably well (and it would be even faster/better if you went UDP). Using GPRS may still have too much latency, depending on your needs, but it's a tradeoff (it's very convenient, almost always there, other methods are not).
The ideal way to do this would be to combine whatever is available and fallback gracefully, and test the latency once connected to make sure the network is up to par, or bail out. For example, use the local WiFi network if it's available. That is to say, have both devices "register" with a third party server as they startup, then if they're both on the same WiFi just have them communicate directly (run a server on or both, and clients on one or both, get information about discovery and such from the registration). If they are not on WiFi then fall back to GPRS, but realize there will be more latency, of course. Finally, once any method has been established send some test messages to check latency.
I know this isn't really an "answer," it's more of a stream of consciousness about this, but it wouldn't fit in a comment, and I thought it might help ;).
(Full disclosure: I've worked on Android apps that connect multiple mobile devices and multiple TVs, some over GPRS, some Wifi, some directly. I work for a company (MOVL) that makes a platform for stuff like that, it's more focused on mobile-TV-mobile, but it supports mobile-mobile also. In all it's not too hard to do yourself with regular networking, the tricky part is getting the latency down and picking the correct method for each device.)