I'm trying to figure out if this is even possible:
I'm interested in writing a simple game that could be played in a peer-to-peer setup, rather than having to go through some intermediary server. I was thinking of using something similar to how SMS works, but I don't know if those routines are accessible.
From what I understand, SMS is just a data packet with a specific structure, and on a certain port, that gets sent to a phone number as the unique identifier, rather than an IP Address. If that is the case, is it possible to use similar routines to what SMS uses in order to send messages to another phone, but in such a way that SMS will not pick it up, and if the app that would understand that packet is not running, then the data would just get ignored?
You can write Apps that send SMS and receive SMS. Some things to keep in mind:
SMS tend to be expensive, especially when compared to IP traffic.
The user must grant the permission to send and read SMS to the app. He probably won't do, beacuse he knows it's expensive.
Even if the users contract offers a SMS flat rate, providers may limit the actual number of SMS being sent or forbid automated, high-traffic usage.
SMS might be much slower than IP packets.
If a user tries to play with someone who hasn't installed the App, that poor person will have his SMS inbox flooded with those SMS.
So it's mostly a bad idea to use SMS for that purpose. Some alternatives if the users are close enouth to each other:
Use bluetooth.
Use Wifi (Most android phones won't allow ad-hoc connections, but some phones can act as acces points so that others can connect to it).
Maybe: Use NFC (only some of the newest phones have this, and I don't know if you can use NFC that way).
Use P2P over internet (which requires at least one provider to allow incoming connections on their network with a public IP, e.g. no internal NAT).
Use a server that handles the traffic between phones.
Related
I want to make an application is via WiFi would send and receive data without sending them to a specific recipient. I explained to the example of a simple chat: The user sends a message via WiFi, but without a specific destination. As a result, his report available to all users nearby. Similarly other users can receive and send messages. I also want to realize the function of repeater, where each user's device not only receives a message from the other devices, and retransmits them to others allowing increase the coverage area of WiFi connection.
But at the moment it is not possible to send data without a specific recipient. The same WiFi Direct necessarily require pairing before data transfer. Can not specify that the recipient is unknown.
Recently I heard the news about the technology WiFi Aware, which involves greater interaction between WiFI devices. Please reply, WiFi Aware allows to do what I described above? Namely - the transfer of data and we will without a clear indication of the recipient and the need to do additional work (eg preliminary pairing between devices).
If WiFi Aware allows to do what I described - when it is expected to release its API? In particular, for Android devices. And if not - you can tell me how to implement what I need? And in general - it is technically possible?
Thank you for your time and sorry for my bad English.
You should try to look into nsd via wifi-direct. This Network Service discovery via Wifi-Direct. What this helps you to achieve is broadcast information to all listening devices.
On the device which wants to convey the information you addLocalService and on the other devices you should discoverServices. In the ServiceInfo object you can the pass the information you want to communicate to the other devices who are listening for services. Please try to study from the link attached above.
I am not very sure about how repeater will work with this.
I want to know if there is any way to communicate users without internet connection to a server.
I thought it might be possible through SMS and machine-readable encoding. However this question confirms that iOS apps allows sending but not reading SMS: iphone app reading sms
I've also read a lot about using USSD but it seems that mobile opened messages aren't possible in iOS (dial USSD code from iphone programatically) and while in Android is possible to call a code programatically there is no USSD API to, nor it's possible to send USSD messages silently.
Is there any way to transfer data between my app and my server with only basic voice-sms signal?
You are correct that SMS could be used to communicate with the server, if the server has access to a GSM modem. For large volumes of SMSes, you'd expect to have an internet connection between your server and an SMS gateway that connects directly to the messaging centre in the mobile network, instead of a modem.
This is the model of the SMS voting servers.
You can send/receive SMS as long as you have a GSM network, and you're right; no IP connection is needed.
The Android platform lets you send and receive SMSes - see here.
Disadvantages are that SMS can be expensive, and has no guaranteed delivery, and no guaranteed delivery time. It's not suitable for real time communication.
USSD is another form of communication between a mobile device and the network that's built directly into the GSM network, but USSD messages are owned or licenced by the network operators, and aren't free for customers to use, as SMS is.
EDIT: USSD isn't a native protocol in CDMA, but various implementations are available from different operators. For example, here's a patent application describing an idea for one such system, which does not appear to require an IP connection. Googling "USSD CDMA" also gives various news items about commercial implementations, technical details unknown. I think you just have to find out what your target operator(s) offer.
I haven't worked directly with WAP, but a glance at the WAP Protocol Stack shows that it can indeed run over CDMA, or GSM without an IP connection. There is also a very useful Wikipedia article. My experience testing MMS is that it usually doesn't work without an IP connection, even though it is supposed to (according to that Wiki article, with WAP/SMS). So I would question how far European operators or mobile devices are supporting or testing WAP. Whether WAP is a practical choice could come down to pricing/availability at the end of the day, rather than technical issues.
Well, there are yet other options, depending on the amount of data you need to transfer back and forth to the server.
Instead of sms, for short amount of data you could try to implement an Asterisk PBX, whith your mobile calling your server and then sending other DTMF digits as your data, which would be interpreted by your Asterisk PBX (like an interactive phone audio menu from your cable company). Asterisk is GPL open-source.
Another option (an expensive one and with heavy work to do), would be to generate an audio signal encoded with your data content, and dial a phone number linked with an attached fax/modem pci board on a server, sending that audio like a call. It would'nt need to be a long call, as you could fit lots of data in a short bursts of audio stream.
Your server could check that data by acessing the content on the receiving end. Simply recording the call from the attached fax/modem pci board, or you could use an Asterisk PBX server on a local computer to save the audio file and then process by your server software.
Anyway, you would need to create a new protocol and data encoding type, like you mentioned "machine-readable encoding".
So, for the data types you could just save a lot of short audio files on your mobile and play them as your datatypes, but it would be easier to just go for the DTMF already mentioned above. Or you could encode like this: get the sound spectrum allowed to use through the voice call (Wideband/Narrowband), and divide it by the amount of single characters or chunks needed (take a look at how to encode in base64, to have some ideas). Then create a function to just encode your data as a short audio stream (read about PCM encoding and also read more about Fast Fourier transforms, if you want to complicate (but speed up) even further.
Create a simple protocol like this: first audio packet is a sequence of tones that makes a request, authenticates, and waits for acknowledgement response from the server (which could be just by not dropping the call 1 second after that). The 2nd audio packet is the size of the first frame of data, then the 3d audio packet onwards is the data itself with the size shown before. And so on. Have a look at the ftp protocol description for simplicity. Then you need to refine it so that the time of every packet above is the least possible while mantaining confiability.
For costs saving on voice calling, you could also explore phone number options, like Google Voice, Skype or any Voip service.
Is there any kind of standard/widely used SMS format for Android/IPhone/Windows mobile/Symbian that enables to send/recieve GPS coordinates ('geo tagged SMS')?
E.g. Garmin has peer point SMS format, that enables to send/recieve POIs or just simple points. Garmin mobiles are able parse this format and geographic part of the SMS behaves as a link, so by clicking it it can be shown on map or save to user's POIs etc.
I tried to find a similar SMS format for other mobile operating systems (or a general one...), but I have not found yet. Do you have any suggestions?
If so, is there any library that can be used to construct this kind of SMSs in .net environment?
I am developing a GIS app under .net that can be connected to a GSM modem. My plan is to implement a feature to send POI points to mobiles from my app.
Nope I'm afraid not.
An SMS is just that, a simple message, unlike MMS or voice it carries no state information, no meta data the most it has is a user defined header (For binary messages) and various protocol data unit elements that describe things like the address of the SMS central receiving server and the message length, type and char set.
If you want to do location aware stuff using SMS, then you'll
a) need to have software running on the target device, that can interrogate a built in GPS or other location aware device.
b) can respond to an inbound SMS asking it to send an SMS back with said location information in.
unless you have a web based SMS service then this is going to get very expensive very fast as most operators will charge you (at least here in the UK anyway) 0.14p per single SMS text off a standard consumer sim card, where as many bulk operators (I use Cardboard fish) will only charge you around 0.05p per SMS.
To give you an idea of the difference that's 7 SMS messages in every UK £1 on a consumer account and 20 in every UK £1 on a bulk account.
This is more about an explanation then it is about asking a question. What I am wondering is if its possible to write an Android application that can communicate with another Android phone, given the phone number of the phone I want to communicate with. By communicate, I mean I want to be able to send data to the phone and have my application on the other phone be able to recive it.
If its not possible to do this, then I guess my alternative is to have my application "sign" the phone into a server. Then I'm assuming the server can act a proxy to communicate with both phones.
Any clarification would be helpful!
Check out the BUMP api. It allows you to establish a connection between two (I think more are also possible) devices, and it gives you a channel over which to communicate. The devices need to be "bumped" first, but then it's all fair game.
Any reason why it has to be by phone number? That and i'm pretty sure you can only send data over WAN or local bluetooth/wifi.
Perhaps try something along the lines of a server that has phones sign into it and keeps track of the phones IP addresses allowing them to communicate almost directly to another (kind of like a dynamic DNS hah!).
Look into SMS. I haven't coded for mobile phones in years but I seem to recall that most phone operating systems let an app intercept SMS messages, react to their contents, and prevent the user from seeing them.
As long as you're not sending lots of data, SMS might do the trick.
I am working on an application and one feature that would make it really useful is the ability to share some information, but the other device may not be expecting the data to be sent.
For example, if I am reading a really good book, and I realize that a friend may like it, I could use an application to send the data to him, so he could order the book from Amazon.
But, since he isn't expecting the data, I would hate for the application to be polling a server every so often, as that will be needlessly draining the battery.
Ideally it would be great if there was a way to make a phone call to the target device, send a data packet and end the call.
If it could be done and prevent the phone from ringing, then it would be very useful to me.
I am curious if there is some way to send data between devices without polling.
You can send them a message via facebook or email (e.g. here), or broadcast it with twitter.
These approaches - using an existing infrastructure for messaging - provide mechanisms for discovering your user's contacts / 'friends' and so on too.
Your can send and read SMS on phones if you have the correct permissions.
You could talk to Mashmobile who have a bigger platform that can do peer-to-peer between phones. You could imagine a hybrid that did both Mashmobile for Windows/Android/Symbian and Apple's push for iPhone users of your app.
On future phones, you could use C2DM (which is a application-specific messaging system overlay on gmail - the Android phone user has to have a Google account etc)