I'm currently working on an Android project that will need connecting to a Bluetooth device that will dispatch messages to different nodes. This means that I will have to pass the right messages to the appropriate nodes (many micro-controllers).
At the moment, I can send a string or receive a string from the master micro-controller and I think the best way to solve my problem will be that the master micro-controller node simply repeats and broadcasts the message to all the others nodes. For the Android part, I was wondering if it was a good practice to make an array that will contain the id of the receiver and after the data I want to send. The ID will be on 8 bits and the data will be a string. After I will cast the int to a string and concatenate both strings to send my id+data.
Is this a good way to solve my problem or there is a more elegant way to do so?
It would be more efficient to cast the string to bytes and send it all as an array of bytes. Serious network protocols would never use text data like that. If you're just doing a for-fun trial that's ok though.
Here's the real problem I see with your mesh- infinite exponential propagation. Lets say I send a message to someone, and do it by sending it to all of my neighbors. They'll forward it to all their neighbors. Who'll forward it to all their neighbors. Which if there's ever any loop in the graph will cause it to get sent back to someone who's already seen it, who will forward it again. And it will never die. Unless you have no loops, in which case you don't have a mesh and you're very fragile and will likely fragment. You need some way of preventing retransit of the same message- possibly as simple as a message id field and not retransmiting the same message id again. You'd need a large pool of message numbers for that though- something like a 128 bit UUID.
Related
I have a two access points and one main router in the same network. A server and two access points are connected to a switch (hub) and this switch is connected to main router. When I connect my Android device to access point 2 and send a request (HTTP POST) to the server and connect (automatically switch between two access point when out of range for other) device to access point 1 it makes the same processes twice.
When I send a package ACK, it comes back to ap2 and times out. And the client sends the package again.
Is there any way to solve this problem like sending an ACK back to two access points at once? Or perhaps the problem may be occurring because of something else?
Yes there is a way to solve it. You must solve it in the application layer by implementing a mechanism to make the operation idempotent. To begin, the problem seems to be as you described it.
To make the operation idempotent you can include a counter in the message. The client increments the counter for every different message it sends. On the server side, if it receives a message with a repeated counter value, it knows the message is a dup and it just drops it. You can come up with some corner cases I might overlook but essentially this is how you should solve it.
Let me first explain my problem:
We are using HTTP REST protocol to transmit chat messages. For chat messages, ordering of messages is critical. Since HTTP is a stateless protocol, we are observing that messages are received out of order on server.
For example, if we send A, B and C - received order on server can be C, B and A.
Is there a way to solve this? I am not sure if HTTP requests can be ordered in Android. Even if we try to do so, that might reduce its efficiency since only single HTTP request will be executing at a time.
Is there any established pattern to solve this?
The reason they arrive in an unpredictable order is because such is the nature of networking. Packets travel through different routing points and you cannot force them to be in order. Even if you send them in order, they are not guaranteed to arrive in order.
But the good news is you can achieve what you are looking for in several different ways.
You can wait for the server to respond back with OK, before you submit the next message. That will ensure the order, but you would lose the multithreading.
A better solution would be to tag each message with an order_id or a timestamp. Then the server puts them in order.
In my case I assigned timestamp on each request and then saved them on my db. Users may see their messages unordered especially when they chat very fast. But when they refresh, the server will return the ordered list based on the timestamp registered.
I am trying to create a forum based group chat application on android.I need to be able to draw and send voice messages over chat.
I am confused between IRC and XMPP for chat protocol to use.Can someone please suggest me in this regard.
I feel IRC is better for my application as it is mainly designed for group communication in discussion forums but i am not sure whether IRC supports anything else apart from text messages.
You can send any kind of binary data (images, sound, etc) in plain text using codifications systems, like Base64 for example.
You must take care about chosen codification character domain does not collide with your protocol method to delimit messages. Other common issue is the size of the message protocol allows. Maybe you need implement some type of chunked message in the protocol and some MIME that describes the binary content.
Here you can find a list of common B2T encoding standards.
For draw in "real time", the simplest solution is send an snapshot image to clients with the current image being drawn in the drawer client. If you do it 10 times in a second you get an 10 frames per second animation of the drawing. To optimize that there is a technique called Delta encodig, sometimes called Delta compression. Is a way of storing or transmitting data in the form of differences between sequential data (in this case an image) rather than complete files. So, in the client, you recibe just the diferences betwen two "frames" and the only thing you need to do in client is "merge" the current "frame" with the difference to show the next "frame".
I'd like to trasmit data (in the form of a single extra digit) to the called party when making a call. Both users naturally need to have my app installed.
For example: Person A makes a call to Person B, my app cancels the outgoing call, appends a "*1" (e.g.) to the called number and re-initiates the call. My app on Person B's phone listens to incoming calls and extracts the extra digit from the called number.
Is something like this possible? Please note that I can't use public void onCallStateChanged(int state, String incomingNumber) {} for this, since incomingNumberis the caller's (Person A's) number, not the called number. I need to be able to extract the extra-digit before the call has been picked up, so I can't use por wDTMF-dial-codes.
I've got the "intercept-and-redial"-portion on the caller's side, and the "listen for incoming calls"-portion of the app working, I just can't figure out how to A) transmit the digit so that it arrives at the called party's phone (rather than being dropped by the carrier) and B) get the called number on the receiver's phone.
Thanks!
I think, but I'm not sure, that you can't just transmit data like this. The reason is that the carrier directs calls with those numbers (codes). Transmitting an extra number(or an extra single digit) means wrong (or incorrect) number and will probably cancel the call. What you want to do seems to me like a way to manipulate the network, but I don't think it's possible. The data center of the carrier has probably at least some kind of a check on this.
I don't know why you need those symbols "*1" to be transmitted, but since this is hardcoded, it can easily be hardcoded into your application too. I think that you can use the telephone number to identify the calling party, but if you need to transfer information dynamically this way, it should not be possible.
Maybe you should try communicating directly with the other device, which has your app installed. Here's an interesting THREAD about this, even though there, this kind of communication is used for multiplayer games it provides a way for the devices to communicate.
New to stackoverflow, been very helpful searching, but alas the time has come to ask a question.
I am trying to use an android 2.2 single core phone to do some research. I have implemented an algorithm that does quite a few calculations and produces a lot of data. These data must be processed, and the solution presented back to a client app within a 40ms time frame, then process again with new state data coming from the client. Also, the result of the calculations must be stored to the SD card as a data log. So being new to multithreading and android both, what should I use to do the following in my app: (As a side note, this phone, when in research mode is not intended to be used as a phone, phone will be in airplane mode with wireless off, and all apps that can be turned off will be turned off, and there is no need for UI display or interaction once it is up and running...)
need to process packets coming in over adb on serial port, these packets are state data that the program needs to perform its calcs on. These packets will be coming every 40ms, so I planned on using their arrival to trigger the start of the processing.
need to know if the algorithm is taking longer than 40ms and cancel it if so and send a message back on the serial port that it overran.
the calculation results need to be sent back over the serial connection via tcp and adb
The calculation intermediate data need to be recorded to SD. This can be quite a lot of data, on order of 140k, every 40ms.
So I have had trouble getting all the pieces together. I can't get my head around how a single core is going to keep up with all this going on at once?
So here is my thought, please tell me if I am headed in the right path. I am not asking for you to solve my problem, only any advice on how to break this beast down:
So i start a service to process the tcp packets coming in from the client
Use a service bound to the main worker thread to handle writes to the SD card
So assuming this setup, can i make the algorithm part of this somewhat deterministic so that it always runs if it gets a new tcp packet, and preempts the SD write going on in the background?
Argh...should have picked something simpler for my first program
Thanks.
Yes I think you are right, that it would be better to pick something easier for your first App ;)
But as far as I understand what you are trying to do, I don't think, that you need asynchronous multiprocessing. You get some data want to process it and pass a result. I think a HandlerThread is exactly what you are looking for. It is able to recieve Messages
with data inside. You send them to the Handler and process them in an overridden handleMessage(Message m) method. So everytime you recive a Message you could just log the Time
and see if the last one is older than your limit. If it is, you could just throw the Message or the whole queue, or send a Message to your serial-port inicating the overflow.
This could be implemented as you suggest in a Service. Another HandlerThread can be started with Thread.PRIORITY_BACKGROUND to write everything to SD.
You can send Messages even very compfortable if you apply a Messenger to the Handlers