I have an AIR server application. Several mobile clients connect to it. Everything works good, if there is only one client, but when the server sends data to several clients in a loop, the clients fail to process the data immediately. The data is late by one step.
This bit of code is inside a for loop:
clients[i].client.writeObject(data);
clients[i].client.flush();
Only the client sending the data is getting the update from the server. Everyone else is quiet for one step. If the client sends another message, then all other clients are updated to the state of previously sent update.
The code is fine on clients, as the client running on a computer is receiving the updates on time. Only the mobile clients are failing to update.
What could be the reason for this issue?
What is the proper way of sending data to multiple client sockets at the same time?
I have solved the issue by setting a timer to delay the data transfer by 1/3 of a second. Less delay time caused the same issue. I do not think it is the only solution, but it worked.
The problem with this solution is, if the there are 100 clients, the last will receive the data updates in 30 seconds.
Related
We are successfully communicating to OPC UA server reading and setting tags. Everything works fine but only issue now is that writing tag value takes a long time around 600ms per tag. So to set 10 tags it takes around 6 seconds which is unacceptable in production environment...please suggest.
How long a write takes is almost always the responsibility of the server, not the client, so there is probably not much else you can do on the Milo client side other than make sure to batch your writes into a single call whenever possible, which it sounds like you are already doing.
You could verify this for yourself by connecting without encryption, capturing the traffic in Wireshark, and verifying that the delay you see is between the request being sent from the client and the response being received from the server.
I have 15 worker clients and one master connected through internet. Job & data are been passed through REST api in json format.
Jobs are not restricted to any particular client. Any worker can query for the available job in regular interval(say 30 seconds), process it and will update the status.
In this scenario, how can I prevent same records been sent to different clients while GET request.
Followings are my solution approach to overcome this issue:
Take top 5 unprocessed records from the database and make it as SENT and expose via REST GET.
But the problem is, it creates inconsistency. Some times, the client doesn't got data due to network connectivity issue. But in server, it will be marked as SENT. So, no other clients can get that data. It will remain as SENT forever.
Get the list from server, and reply back the list of job IDs to Server as received. But in-between this time gap, some other clients also getting same set of Jobs.
You've stumbled upon a fundamental problem in distributed systems: there is no way to know if the other side received your message. You can certainly improve the situation with TCP and ack messages. But if you never get the ACK did the message never arrive, did it arrive but the recipient die before processesing, or did the recipient send he ACK and the ACK get dropped?
That means you need to design your system to handle receiving data more than once.
You offer two partial solutions; if you combine them, your solution starts to look like how SQS works. Mark the item as pending_ack with a timestamp. After client replies, it is marked sent. Any pending_ackss past a certain time period are eligible to be resent.
Pick your time period to allow for slow network and slow clients and it boils down to only sending duplicates when you really don't know if the client died or not.
Maybe you should reconsider the approach to blocking resources. REST architecture - by definition is not obliged to save information about client. Instead, you may want to consider optimistic concurrency control (http://en.wikipedia.org/wiki/Optimistic_concurrency_control).
I'm making a XMPP client and I would like if there is some timer or memory cache for messages received because i send 1000 messages to my client and the server send 1000 messages ok but my client only receive 300.
Possible Solution:
...Overcoming those limits
Every time HTTP has a solution for “fixing” XMPP.
The first two limits can be fixed by running a WebDAV server. Upload to the WebDAV server, share the link. That’s a solution everyone can do without XMPP client support. Of course, having a way to do that transparently with client and server support, with signed URLs (à la S3) would greatly improve the process.
For the connected socket problem, there’s BOSH. That’s basically running XMPP over HTTP. With the added bonus of having the server retaining the “connection” for a couple of minutes – that fixes my iPhone problem. Once I relaunch the client in the two minutes window, all the pending messages are delivered.
Your receiver is receiving only 300 messages means they might be the offline messages. If this is the case you need to increase the Per-user offline message storage limit in your admin panel.
I would like to suggest you to go for message archiving and retrieving instead of depending on offline messages.
Hope this helps you :)
I've some service that's being called by a Mobile app.
The mobile app need to be up to date with the server.
So, Every 1 second I do check the server for any additional data, if found I got the data from the server (repeating task).
Is there any problem from sending an HTTP request every single second (most of the time the response is very small, just to tell the client no data found)?
I am using Oracle App server for Server and iPhone for Client.
Thanks.
It will probably eat your client's battery, and create a lot of load on your server.
You can try commet long polling approach or the newer (and not well supported yet) WebSockets instead.
I have an application made up of a server which sends occasional messages to Iphones. The latency between the two devices is important to the problem domain - if it takes less than a second for the message to arrive, everything's fine; if it takes more than 5 seconds, there's almost certainly a problem. The server-side messages are time stamped with the server time.
Using the cellular data connection, we see occasional delays, but we can't quantify them, because there's no guarantee that the Iphone's clock is synchronized with the server; one our test phones, we see different times for different carriers.
Is there a simple way to synchronize time between the Iphone and the server? I've looked at (S)NTP, which seems to be the right way to go.
Any alternatives? We only need to be accurate within seconds, not milli seconds.
I'm not sure what the exact situation is, so this may be a non-solution, but:
Presuming that you want to figure out the latency between the phone and the server (and only this) at set intervals (decided by the server). Presuming also that the error checking is done server-side, instead of synchronizing clocks, you might go with a "ping" approach.
Server pings client iPhone, and starts a stopwatch.
Client immediately pings server.
As soon as client ping reaches server, server stops the stopwatch and checks the time.
If I misunderstood your problem, apologies.
Well, a somewhat simplistic solution is that you could have the phones tell the server what time they have at various times and keep a database table of deltas. Then adjust your reported timestamp to the serve's time r +/- the delta. iPhones are synced to the carrier's time server to the best of my knowledge. The other possibility is to have both the phone and server query a common time source on a daily basis. It's unlikely that the time would vary much over a single day.