We Keep Coding

Forwarding a text message via GSM modem using Java

I am using Java CommV3 drivers to interface a GSM modem (Huawei E173) with a Java Application. I am trying to forward a text message to several numbers present in a mySQL database. I always receive a PortInUseException. However, manually sending and receiving messages works perfectly fine using the same code. I have tried using a delay of upto 15 seconds between messages (in the loop) but I still face the same problem.
What am I missing here? Do we have an AT command for forwarding messages to multiple numbers? Is there a particular delay that I should be aware of?

Though this is an old question, I might be able to provide a suggestion.
If you are using a multi-threaded approach for sending and receiving, you must ensure there is exclusive access for each of these threads to the resource (in this case, your GSM Modem). So, make sure you close the connection to your serial port vice versa during RX/TX.
I can provide you more suggestions if you could post a code snippet.

android multi player game over network

I'm programming an Android multi-player game, which basically consist of a server where the clients connect and exchange messages. When the player connects to a server, a player list is return to him/her. A player can then select a user to challenge - of course he must select a player from the player list, which only contains connected users.
When a player1 challenges player2, a message needs to be transmitted from player1 to the server, which in turn must send a message to the player2, notifying him about the challenge. The player2 can then accept/decline the challenge.
I can use the following techniques to make this happen:
Use custom server/client with Java socket programming. The server basically accepts a connection from the client, spawning a new thread for each connected client. The problem with this are:
There needs to be a persistent connection open from client to server wasting battery life of the android phone. This is not really big limitation since the battery isn't consumed that much.
When I'll want to develop another game I'll have to rewrite the client/server code from the scratch - also choosing another port to listen for incoming connections - the whole concept gets rather difficult to maintain.
I'm also worried if this is the way to do it. Spawning another thread for each clients sound quite a lot if thousands clients are connecting at the same time. But I'm guessing the PC games do it like this. Not sure about android.
Use Java REST jersey to build the client-server on top of HTTP. This would be a perfect solution if the server could easily send notifications to clients. There are actually multiple design decisions here:
the client pulls the server for any new data/notifications every few seconds - this is really bad, since we're stuck with non responsiveness, delay, etc.
the client can send a waiting request to server, so the client receives the response only after some data becomes available. This is better, but can still produce a delay when two notifications one after another need to be sent to the user. The first notification is sent instantly, since the client already has a connection open, waiting for data to receive. But we would have to wait for the client to initiate another long http request to receive the second notification. The problem gets bigger as there are multiple notifications that need to be send in a row to a specific client.
the client can initiate a http streaming, where the communication is left open when the request is handled, so the server can also send multiple messages to client whenever it wishes. The problem here is that I don't know how well this works on Android. I've looked at several implementations:
Java jersey + atmosphere: didn't succeed in actually making it work. This seems the most promising, but I don't want to spend too much time on it, since I'm not even sure if it does what I want.
Deacon: seems pretty neat, but after seen the video tutorial on their official web page, I'm not sure that it can do what I need. When a player1 challenges player2, can it send a notification to player2 letting it know about the match request?
I would be glad to know how other multi-player games handle the network communications, if the two players are playing the game over the network.
I'm also open to a totally new suggestion how to achieve what I want. I can pretty much code anything, so don't hesitate to let me know of some more difficult way to achieve the network communication.
Let me also mention that I'll be glad to implement a totally specific method to work in my case, so it can be anything that will do the job done, but I'm also looking at more general way for communication between clients and server. So that I can program an interface/whatever and reuse the code in other android games, android applications.
I hope I presented the problem allright and that I'll receive some valuable answers.
Thank you

You should take a look at XMPP. It's a protocol (originally created for chat programs) that allows sending of xml data between users.
It has a separated client-server relationship, so that you can focus on developing a client application fit for phones, and a different server depending on your needs.
There are loads of information available on the protocol (I should know, I wrote a thesis about using the protocol in game applications), but you can start by looking it up on wikipedia to see if it is what you want.
aSmack is a library for creating android xmpp-clients. It takes some tweaking to set it up and get everything to work, but once you do, it's neat.
EDIT: relating to the answer suggesting using the C2DM:
from the c2dm docs "Sending large numbers of C2DM messages":
Are you sending C2DM messages too frequently? If you need to communicate with your application frequently over a short period of
time, C2DM is probably not the best solution. Instead, consider
implemeting XMPP or your own protocol to exchange messages, and use
C2DM only to send the initial notification.

It sounds like Android Cloud-to-Device-Messaging might be what you need
Push notifications without the app having to keep a connection open

I would vote in favor of some message passing technique - like activeMQ, rabbitMQ, zeroMQ eor something like it. On the server side you may stick with java , or javascript ( like
node.js ) - such solution would provide most performance and minimal latencies.
If latency is not that critical, you may as well use REST calls with JSON

Play framework longpolling in online game

I'm working on a browser game with the play framework, and I definitely need longpolling, but I don't quite understand how to use it. WebSockets would be perfect for this, but it's not supported by that many browsers yet.
Here's what I want to do: When the user logs in, and navigates to the play game controller, I want to start a connection, and keep it open. I want to do this for all users that are online, so I can show a list of them on the site, so they can play with each other. I've looked at the documentation, but I don't understand how I could implement it in my case. Because there simply isn't anything I want to calculate (in the example they're generating a pdf) I just want the connection to stay open.
What I'm also wondering is, how I should keep track of all these open connections? Right now, I just have an online column in my users table in the database, which I update. SO everytime someone connects I have to update the database. Are there better ways to do this, or is this fine?
And lastly, assuming all of the above works. When player A, selects player B to play with: how do I notify player B of this? Do I just send some JSON code, and change the page with javascript, on player B's side, or do I send him to a totally different page? I'm not sure how to communicate when the two connections are established and the game has started.

Firstly, I think you need to appreciate the difference between Websockets and Long Polling.
Websockets creates a connection and keeps it open until the browser terminates the session, via some javascript or the user moving on from the page. This would give you the desired nature of what you are requesting. Looking at the Chat example in the Play download will show you how an entire Chat application is handled using Websockets.
Further to Pere's answer regarding Play's statelessness. The Play creators have suggested that a single Websocket connection, regardless of how long it is open for and how many requests are sent back and forther, is considered to be a single transaction. Therefore, saving to the database in between each Websocket request is not needed (again, you can see that nothing is saved in the Chat example). Using this method, you would be expected to save the details when the Websocket is finally closed, or indeed all Websockets, depending on your use-case.
Long Polling on the other hand opens a connection to the server, and the server simply waits until there is something to send back to the client. If you need to push any data to the server, you would do this as a separate AJAX request, so you would effectively have two requests open at once. You don't necessarily know when a user logs off, unless you send a request just as they leave the page, to let the server know they have gone, but this is not always successful. Long Polling can work, but it is not as neat a solution as Websockets, but as you say, this is not widely supported yet.
My suggestion would be to study the Chat example (as it has a Long Polling and Websockets version). This will be the most effective way to get up and running with your requirements.
As for your final query regarding how to notify the other player. In Long Polling, you would simply respond to the suspended request with some JSON. With websockets, you would send an event back to the client. Again, both approaches can be pretty clearly figured out from the Chat example.
I have also written a Blog post on Websockets, which may help you understand this process a little better.

On the Websocket part, as you can see here (1st answer) the support is not so bad, and you have a Javascript fallback if there is some problem with the browser. This would simplify your scenario, as long polling may be more complicated to manage.
On the issue of keeping track, as Play is stateless you have to store the flag in the database and remove it when they close the connection. Otherwise you are breaking the statelessness.
About the notification, you have to send some message to B, but don't move them to another page as it may be confusing and cause bad user experience. Use Json to pop some message (in a div) alerting them of the game starting or the request to play.

I'm not using the "play" framework.
But I've been lately researching and tinkering with http-based long polling. Websockets, if available, is much more appropriate for realtime messages!
As for long-polling, I found that using a "cargo truck" analogy helped me reason about long-polling quite effectively. Here's a little note I wrote on the subject:
http://dvb.omino.com/blog/2011/http-comet-realtime-messages/
Perhaps you or future greppers may find it useful.

You might also want to take a look at the Juggernaut project which is based on node.js and Redis and gives you a "realtime connection between your servers and your client browsers". When using a Java Redis client like Jedis, you should easily be able to integrate the whole thing with the Play framework!

SMS Based Application How To

I would like to develop an application which users interact with on an sms platform. Its more of an experiment to learn something new. Any pointers on technology to study and things to look at as pre-requisites before diving in? Thanks

First, you'll need a device that can act as a wireless modem to provide you with a connection for the gateway. If your cellphone supports tethering and you have an SMS plan, it would be pretty easy to use that. Otherwise you'll need to get a modem and a plan to go with it. I'm not sure how close to the metal you want to get, but you can then use SMSLib to listen on the device and wait for incoming messages. With this setup you can both send and receive messages. It is also possible to use something like Minicom to send commands directly to the modem for experimenting.
As another approach, you could also use a vendor such as Clickatell as an API for interacting with an SMS gateway. They seem to be able to handle both sending and receiving SMS on behalf of their clients.

You can easily do this with something like Twilio (where I work). Here is a howto for sending/receiving in PHP using just HTTP POST requests: http://www.twilio.com/docs/quickstart/sms/

What can you use to get an application to be able to receive SMS message?

Do you need to use some kind of provider?
Can you setup your own SMS server?
Does any open source solutions exist?
I am an SMS newbie so any insight on how this is accomplished would be great. I am partial to Java but any language is fine.

This is easy. Yes, you need a "sms gateway" provider. There are a lot out there. These companies provide APIs for you to send/receive SMS.
e.g. the German company Mobilant provides an easy API. If you want to receive a SMS just program a simple PHP / JSP / s.th.else dynamic web page and let Mobilant call it.
e.g.
Mobilant receives a SMS for you
Mobilant calls your web page http://yourpage.com/receive.php?message=...
You do what you need to do
You really don't want to setup your own SMS Server or Center ;-) This is really expensive, takes months to setup and costs some nice ferraris.
Use a provider and pay per SMS. It's the cheapest and fastest way.

I used kannel on a linux box with an old mobile phone connected via a serial cable to the box. Got a pre-paid card in the phone as I was using it for private use only. Worked like a charm!

You might take a look at Gammu if you're running on a Linux box:
http://www.gammu.org
Using Gammu, you can configure it to periodically poll a mobile phone for new SMS messages. When Gammu finds new messages, it can store them in an SQL database. You can then write another program to periodically poll the database and take action on new messages.
Using this general setup I successfully deployed a homemade 2-way SMS application. I configured Gammu to pull messages off of the phone over Bluetooth. Gammu placed them in a MySQL database, which I had a Tomcat web application periodically poll for new messages. When a new message was found, the system processed the message.
This is a somewhat "duct-tape and bailing wire" setup, but it worked quite well and was more reliable than many of the "professional" SMS gateways I tested beforehand. YMMV.

We've used mBlox (http://www.mblox) in the past, as they provide comprehensive international coverage, premium SMS, various levels of Quality of Service vs Price, and a solid Java-based API for both inbound and outbound SMS.

You will need an SMS gateway, googling "SMS gateway" will reveal many. I have used http://www.clickatell.com/products/sms_gateway.php with great success.
I do not know of any open source implementations, but will be monitoring this thread in case someone else does!

First, you need an SMS gateway. Take a look at Kannel SMS Gateway.

Agreed with Kannel. You can set it up on a LAMP server with a GSM modem too.

I'm not up with Java, so here's a nice guide on how to do it in Ruby on Rails: http://www.lukeredpath.co.uk/2007/8/29/sending-sms-messages-from-your-rails-application
If you want to send 'true' SMS you'll need to use an SMS gateway, (use of one is outlined in the above guide).
You can use MMS to send messages, to an email address that looks something like 1234567890# messages.whatever.com. You can use mail functions to do this. There's some information about that here: http://contentdeveloper.com/2006/06/open-source-sms-text-messaging-application/

TextMarks provides a service where they map an incoming SMS to them to an HTTP GET to a URL you provide and then send the response back as another SMS. They don't charge you if you let them add some advertising to the reply SMS. The problem is they don't provide this for free anymore for T-Mobile due to T-Mobile charging them. I'd be willing to pay per message, but they charge $0.20 per user-month, which is rather steep. Anyone know of anyone who provides this service?

You actually don't need an SMS gateway; nearly every cell phone can send/receive SMS messages to/from any email address. I built an SMS service (http://www.txtreg.net) using Nearly Free Speech's ability to forward email to a URL as a POST request. User sends a text to an email address, PHP script processes it, and sends an email right back to their phone.

Try SMS Enabler software. To receive SMS messages it uses a 3G/4G/GSM USB modem connected to a pc. It can forward incoming messages to a URL over HTTP, or store them in a database table, or write them to a CSV file, in real-time.