I am trying to create a text-based multiplayer game for android (similar to oldschool MUDs). I currently have a basic wcf service working - I can make a request on my android app and my server responds with a blob of xml data.
However, I am unsure if this is a workable strategy down the road - if using WCF, I would be limited app side by the number and frequency of requests I could make to the server. A socket connection would seem to provide the fully duplex communication I need but I am unsure how to implement this (and I've read Android may not support this duplex socket communication as I describe?). In any case, guidance here would be greatly appreciated.
How frequently could I reasonably hope to poll my WCF service from an android phone on 3g? Is this fast enough for something like chat between multiple users through a server?
Is there some android socket code I can look into? Can I host my own socket server using either visual studio (IIS?) or eclipse?
Related
I just have read about MQTT protocol and wanted to try out a PoT/PoC. I would like to know the steps that I should take up to start with development of an Android App - to transfer raw data that’s captured during the journey of a driver in a car from OBD to the back end and then process it at server end and send information to an android app.
So what are the requirements and set-up I would need at server OBD and at android client?
Thanks
Your question is very broad and I don't know the first thing about how the onboard monitoring tools of vehicles operate so I'll just write what I know about setting up an MQTT communication channel between a server (.Net or Java) and the Android client.
If you want to setup some sort of MQTT communication channel between your server and the android app, you should start by
Setting up the server: Install ActiveMQ and enable MQTT protocol on the machine you'll be hosting it on(http://activemq.apache.org/mqtt.html). There are other queuing technologies out there supporting this protocol as well so you're not limited to ActiveMQ but it's free and very configurable. Additionally, have a look at RabbitMQ since it also supports MQTT (http://www.rabbitmq.com/mqtt.html) and try googling and reading pros and cons of these queues. As a disclaimer, I've only used ActiveMQ and Solace (extremely expensive middleware solution) so can't say anything negative/positive about RabbitMQ or any other queuing technologies. Just make sure whatever you choose supports guaranteed delivery and message persistence in case you need them.
Write your server code: From what I gather, you want your server to be a listener in most cases but also to be able to publish to a queue so that your app(s) can receive server communications. What you probably should do is to use at least 2 topics for this purpose. One for sending data from the Android phone to your server and one for receiving data on the Android (sent from the server). Depending on the programming language of your server, pick the correct drivers and work with them. All of them will support both subscribe and publish but not all will support MQTT so be sure to check this.
Write your client: To enable and work with MQTT in Android, you can start by reading this (http://www.eclipse.org/paho/files/android-javadoc/index.html). There are examples in the paho source code that will guide you through setting up the queue and subscribing and publishing to it.
Socket programming question here.
My interface comprises of an Android device(client), A wireless module hosting an access point, and an Arduino Uno(server).
My Android client class works when 1 user connects and sends commands to my Arduino server class.
I want to make my program friendly to many users at the same time. My server will only read in values from 1 connected client at a time.
After some research I've found that Arduino does not allow multithreading naturally, which is why i've decided to look into a number of libraries.
The Arduino library that I've decided to use for this specific issue is protothreads. Unfortunately, i've been unable to find any examples of creating a server with Arduino to accept a client's commands. Furthermore I'm having a lot of trouble figuring out how to make this library work in my favor.
Now for my question,
How exactly can I allow my Arduino server to constantly listen for
incoming messages from more than 1 client device?
Or is there something I can do on the client side that would make this communication possible?
Could you get away with accepting the socket responding and the closing it. Similar to a web page. As not to have multiple sockets open at once. Note uno only has 2k of ram flash goes quick. By one and close each stands alone and naturaly allow many different connections. Just one at a time.
I'm looking for options for communication between an Android device - running a native app - and a website.
In basics, the Android device is just a sensor for movement, while the website is the receiving end and will process the sensor data. The website will then have to visualize this movement.
The goal is that this happens instantly and constantly, as the sensor data can easily reach up to 50 updates a second.
I'm looking for some proper options and possibly shared experiences for streaming this data as far as possible;
So far it has crossed my mind to;
Use techniques like Bluetooth, Wifi Direct or USB. Probably not
reachable from a website.
Use a Node.js server for a simple socket connection.
Use Google App Engine. The channel (java) client would be nice for
this, but it seems that the app engine can only be the transmitting end.
I would do this:
Webserver: node express + socket.io
Android device: use https://github.com/Gottox/socket.io-java-client to stream events to webserver.
Browser: uses socket.io client to get a live stream of events.
The node socket.io server just takes the sensor data and broadcasts it.
About socket.io:
Socket.io uses Websockets. However, if the client doesn't support Websockets, it falls back to long polling etc... to emulate Websockets. On top of that, it gives you a pub/sub framework which Websockets doesn't provide out of the box.
The new version of socket.io (available on github) uses engine.io to provide the websocket abstraction and then puts a pub/sub framework on top of that.
In appengine use a frontend to post data to it, no need for 2way channel. If you really want 2way use sockets.
I'm trying to develop a proyect like PTTDroid, I mean a Push-To-Talk or Walkie-Talkie application.
The issue is that in this app you can´t use 3G to access the web, so I've decided to use a Node.js server and implement an Android client to comunicate with it. I tried to do a multiplattform proyect using Phonegap the problem is that for audio record you can't access to buffer, you can only start and stop or pause the recording process but not send data while capturing. So my problem is that is possible to streams audio capture in real time by native Android functions (Audiorecord class) with a Node.js server by Socket.IO or similar?
I discovered this project, Asimi JS, but I don't know if someone else knows a better way to do what I want.
Thank you very much for your help!
It is certainly possible to do it, but a standard NodeJS http server would not be advisable as it uses tcp. You want to use UDP as a transport layer for audio, since it will be faster and the small packet loss that can occur will most likely not be a problem.
To be completely honest with you it sounds like you need to write a few demo applications on the native platforms - so do not use phonegap. You need native platforms in order to access things suchs as the mircrophone and to stream over UDP.
When you have a demo working, you can go on and try with another platform afterwards, but start with a simple setup instead of trying to do it all at once - if it was that easy, someone else would have done it before you.
Let me recommend a simple UDP server in whatever language you are most comfortable with such as (NodeJS, Java, C, C++, C#). Let the UDP server receive and save the content into a file that you can then play back on a desktop computer to verify the result. As a simple client, build one either on Android or iOS, and stream a file that you have already recorded and included in the app. When you have this setup working, you can try to capture the microphone, then do a user interface, then support multiple phones, then build a server which records the conversations, then build a user database, and so on a so forth. But start with a prototype of your main feature.
I've finally discovered and solved my problem (at least that's what I think)...First of all I created a server to send and receive UDP packets by DatagramSocket and after that, to achieve communication between server and client, when I was connected by 3G, I needed to have a static port and IP, that's why my server couldn't connect with the client. With data connection, the user IP and port is not always the same and you have to keep the same socket always opened if you want to send and receive. On the other hand the server has to store the adress and port from the client in the moment of connection.
Thank you very much for your help ExxKA
I'm building a multi-OS mirroring system which I would like to implement using a hybrid client-server and p2p communication method (at least that's the best way I have of describing it).
My issue is that at some point I have a central server (appengine, so there are limitations to what I could do because of time and networking capability constraints) that would need to get a message to a host of different devices which are not necessarily running the same OS (Windows, Android, iOS, Linux, etc...).
Android and iOS (or any other mobile platform) are the main problems it looks like I will be having on 2 levels.
1 - They are both limited by battery power (more so than a laptop and desktops shouldn't have that issue at all), so whichever method I use needs to take that into account.
2 - NAT (harder because the user has relatively less control over their firewall than on a network that they are running). My central server will maintain a table of which device has what IP address, but from what I understand if there is NAT or a firewall it won't be able to get to it if the port was not forwarded.
Since I will be writing a specific client for each OS I prefer a solution that is more universal. I have been leaning towards writing an extremely simple HTTP server that sits on each client and takes requests (which appengine is able to send) and treats them as messages that alert the client to perform an action (either with the server or another client). However, I run into the issue of NAT/firewall. For instance if appengine needs to send a message to AndroidDevice1 it would grab its IP address from a table and make a request to it. However this doesn't work if the ports aren't forwarded correctly, and if the user is on 3g/4g the firewall is controlled by the data provider.
Because of this, I started thinking about using Android C2DM but I want a solution I could implement across platforms.
The only other method I could think of is to just have the client poll the server for messages. This has the battery and network consumption issue though.
Would there be any other way to implement this, and if not, which one of the above methods are best in terms of balancing usability, power and data consumption and user input (the less the user has to do to get the client set up (ie port forwarding, etc...) the better)? Please note that I do not intend for this to become a discussion/flame war but a logical presentation of facts.
Thanks in advance!
You can create a persistent TCP connection from the device to the server and then communicate over this open connection. This would be a very simple connection with keepalive packets for the most part.
In theory this would consume some battery through the radio, but in practice I have experienced that the battery is not affected much at all. Key is to keep the communication over this line to a minimum.
If AppEngine does not allow this approach, you can run your own socket server and then communicate between this server and the appengine server using REST. A socket server I have used is Apache MINA and had no issues with scalability.
Another problem you will have with this approach or any other approach is that on iOS (afaik) you cannot keep a tcp socket open when the App goes into background. The only thing to communicate with the iOS device is Apple Push Notification Service
I would prefer rather than having HTTP Connection you should create TCP/IP tunnel and make communication fast and reliable. I have one Chat application which runs perfact for me using TCP/IP. If you use this you will have same logic for multiple platforms. Only thing you need to write is different code for iOS and android.