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.
Related
I'm using https://github.com/google/go-gcm to send push notifications from our Go backend to Android devices. Recently, these push notifications started failing because the call to SendXmpp() was returning with the following error:
write tcp <IP>:<port>-><IP>:<port>: write: connection timed out
Restarting the Go process that called SendXmpp() makes this error go away, and push notifications start working again. But of course, restarting the Go process isn't ideal. Is there something I can do explicitly to handle this kind of error? For instance, should I close the current XmppClient and retry sending the message, so that the retry instantiates a new XmppClient and opens a new connection?
I would recommend using or implementing a (exponential) backoff. There are a number of options on GitHub here; https://github.com/search?utf8=%E2%9C%93&q=go+backoff though that's surely not a comprehensive list and it's not terribly difficult to implement.
The basic idea is you pass the function you'd like to call in to the back off function which calls it until it hits a max failures limit or it succeeds. Between each failure the amount of time waited is increased. If you're hammering a server, causing it to return errors, a method like this will typically solve your problems and make your application more reliable.
Additionally, I'd recommending looking for one that has an abort feature. This can be implemented fairly easily in Go by passing a channel into the backoff function (with the function you want to call). Then if your app needs to stop you can signal on the abort channel so that the back off isn't sitting there with like a 300 second wait.
Even if this doesn't resolve your specific problem it will generally have a positive effect on your apps reliability and 3rd party API's you interact with (don't want to DOS your partners).
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 have three Android devices with the same app, but I need that the three devices start the app simultaneously.
I have a server too, and the app exchange data with this server (developed in NodeJS).
I thought that all devices can connect to the server and wait until a response. But I don't know how to do it with Node. I used clusters in Node but it didn't work, because I don't know how to synchronize all these 3 clusters.
How can I do that? Another idea?
Thank you.
Well, it's easy to implement with generic events in node.js. Create some special event, and keep requests without response until the event is triggered, what obviously happens when 3rd request is received. node.js is very powerful in that.
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.
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