Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 8 years ago.
Improve this question
I need to build a simple interface between 2 instances of the same app running on 2 different iPads, which can communicate between themselves.
The idea is to create a permanent link between them (by exchanging some kind of Id), that would be possible to keep (possible by storing the Id) even after one or both the iPads reboot, without the need of user intervention.
For the sake of context, that interface could be used, for instance, on a shared grocery list app, or on a 1-to-1 turn base game.
The Apps would not need to be nearby, nor both would need to be active when data is sent (the receiver could be turned off when data is sent, and receive it later)
I imagine that, if this is possible, it would need to be done using gamekit. Can this be done? If so, how?
Thank you
There are so many ways to do this. But in general:
Database: you'll want a server side database to store the common data. The most common options for this are i) host your own database server and create REST API endpoints to access the datastore, ii) use on of the many Platform as a Service (PaaS) companies out there (Parse, Stackmob, Azure, etc). Generally, the PaaS provide a cheaper faster way to get up and running and you'd probably only want your own server if the app was fairly complex. You could always start PaaS and transition to proprietary later if needed.
Synchronization: To communicate between the devices your options are i) client side polling (ie. check for updates to the database every n secs/mins), or ii) push notifications from the server when a record is inserted/updated). For push, you'll want to avoid using APNS (Apple Push Notification Service) as message delivery is not guaranteed (users can decline to receive push notifications) and you'll want to either create your own sockets connection or use a push service like Pusher or PubNub which provide reliable message delivery from server to client. You'll only want to implement APNS for when the app is closed (to notify the user of new activity). When the app is open, use one of the more reliable methods listed above.
That's the general methodology.
EDIT: To be clear, there is no reliable way to do this without using a) a server to store the messages/state, b) a third party service like Pusher or PubNub to reliably deliver the messages between devices, whether the other device is active or not (and really you are then just using their server instead of your own). You could skip using your own server/database and simply send messages back and forth with a reliable service and have them each maintain state locally and synchronize. But note, APNS is not a reliable message delivery service for maintaining synchronization like this.
Related
Only been programming for a couple months now and am finally ready to build a full fledged app. I was wondering, for an app like say Wunderlist (a to do list), what are the industry standards for when to pull/push data between the remote server and core data (where I assume all local data is stored).
Obviously upon sign in a pull is a no brainer. But thereafter how often should I push local changes into cloud? Whenever they are made? And if I plan to eventually make a website from which a user can instantly save changes to the server, how often should I pull updates to the phone (or should I instead learn about websockets and thus push from server whenever changes are made)?
Also I imagine I'll find quite a bit googling around on this, but if anybody can point to where to go to learn how to actually manage the syncing that would be really helpful. All help appreciated!
This is mostly depending on your use case. Let's assume two different options:
Data changes on both sites (or on one site), but is not time-sensitive. The user doesn't regualarly switch between multiple systems or doesn't expect all sites to be directly in sync. In this case you would implement a standard pull-to-reload and push-on-completion behavior (e.g comments on a news-plattform)
Data changes on both sites and is time-sensitive, because the user is switching between Desktop/Browser and your Mobile Application. A good example for this is Apples Notes Application. You can use this on multiple Devices (iPad/iPhone/Mac) and switch between these (on good days).
Option 1 seems to be what you are currently working with. Switching to Option 2 has many possible solutions with different trade-offs. My favorite approach to solve the problem of inconsistencies is sending silent-push notifications to all devices when assuming that the user will soon switch to a different device (e.g. leaving a ToDo-Elements ViewController in a ToDo-List app). For this approach you'll have to implement a push-service on your WebServer with an own API to queue your notifications and distinguish them by their user/data.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have several questions on this topic. For example, I have found a lot of papers like
"Towards Dynamic Orchestration of Semantic Web Services"
"Decentralized Orchestration of Composite Web Services"
and so on... but in practice, I have only found orchestration linked to Bitztalk or ESB (I mean big software programmers).
Is it possible to develop and orchestration language yourself?
What is the best way to develop an orchestration engine?
Perhaps the best source of information on Purpose and Application of Orchestration are the papers themselves which you quoted.
Background
We surf the web on Firefox, type a document on Microsoft Office. These are centralized applications. These types of software sit and work from one place. They work on your computer, they work on my computer.
You go to a supermarket, pickup an item and check-out from one of the many cash counters. Each clerk at each desk has his own barcode scanner and his own swipe card reader. Each of the cash registers on these counters are linked to one server in a back room somewhere. In this setup, the billing software is distributed across the clerk's counters, but the whole application is still centralized. The server manages the stock and records the sales. It is the center of the centralization.
Then you write an email and send it. Say you send an email from your Gmail account to my Hotmail account. There is Gmail's server, and there is Hotmail's server. There are two centers, instead of just one. Now things are no longer centralized - we have a distributed system. Here, failure of one center does not cripple the whole system. If Hotmail goes down, Gmail still survives.
Rather than purchasing from local supermarket, purchase something from an online store. Say eBay or Amazon. In this example, there is eBay's server, and there are the suppliers to eBay. The suppliers manage their own inventory on their own servers, not on eBay's server. There is also the courier company which brings the package to the buyer. The buyers have their own servers as well. The online payment that the buyer made was through MasterCard, yet another separate server. Now we are talking about a really big distributed system.
Purpose
Now that you are making an online purchase, a hell lot of things are bout to happen, which would need more than a bunch of servers. There has to be a master puppeteer who synchronizes activities among these servers. An account has to be deducted. An email has to sent. A warehouse has to be notified. A courier needs to be arranged. who controls this intricate dance? This is your orchestrator.
Application
Most of the time there are many different and independent servers, each owned by different entities. Yet when all these entities need to work together to create a business flow, a "user interaction session", we need orchestration.
Orchestration of the activities among a set of servers is achieved through a master-puppeteer server. In reality, the orchestrator is itself a set of servers. So one set of servers directs another set of servers. These second set of servers is where actual work is being done. eMails are being sent. Images are being compressed. Addresses are being sorted, and so on. The first set of servers (the orchestrator) makes sure things happen in the order they needs to happen.
Implementation
One answer: queues. The one activity that started this whole story was an attempt to make an online purchase. From there, the clicks you made, the commands you sent, were all queued up in these orchestration servers. The command like purchase-this-item or make-a-payment and then payment-received are all queued and then processed one after another.
The orchestration system accepts these commands on one thread, and on a different thread, the orchestration server asynchronously dispatches them to the respective worker servers. So the purchase-this-item command is dispatched to eBay's server while make-a-payment command is dispatched to MasterCard's server.
The worker servers might produce further commands. The MasterCard server, after validating your card number, might decide to send you an SMS. so it add a send-sms command to the queue. That command is dispatched to, say, a Vodaphone server.
This queuing and dispatching logic is called the "orchestration engine". From there, things can complicate. Vodaphone server might be offline. MasterCard might reject the card. The warehouse server might return an out-of-stock response. Then that response will need to be routed to eBay's server which could re-queue the purchase command to some different warehouse. There are server crashes. Disk failures. Power outages, and so on.
Finally
Orchestration is to make sure that so many diverse components, distributed geographically, in different points of time, some are parallel, some are faulty, some are slow, some are malicious, some are illegal,.. all work together towards getting you the damn headphones that you purchased over internet.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I started to make multiplayer game but as I have no expirience I tried it different ways but something doesn't feel right to me.
So, I really need an advice about which platforms/tools/languages/techniches I should use best.
I must say that I don't believe in things such as: Photon, AppWrap, Skiller, Gamooga and others. I dont believe they will scale great and it won't be too pricey, or they are too big (I don't mean size, I mean how much things they has that I don't need) for my needs.
First, I'll describe simplified game session proccess.
Three players starting the game session
Each player receives a question and should answer within 10 seconds.
When player answered he should be able to see any answers that were given already by any other players (if any) and he should be able to see any answer given as soon as it was given. Basically, any answers should be received by other clients in realtime but only after we answered (to avoid cheating). If time is out then any who doesn't answered will receive no score and next question goes.
Deciding winner and goes to the next question. Finish the game session after N rounds.
Second, I'll explain few requirements that I taken into consideration.
Game should be run on iOS/Android/Web. This leaves me no choice but to make it based on HTTP.
I looked for Google Cloud Endpoints about which I was really enjoyed. It has iOS/Android/JS SDKs, Google Cloud Platform has Google BigQuery, and many other great things. But because I need realtime answer delivery I don't know if that suitable (there is Channel API but no client SDK for iOS, and people saying its not that good).
Then I looked for Node.js and long polling (AFNetworking on client side) but it is so hard to manage. I need to serve game state updates to clients (and I need to send deltas). That way I need to track all changes individually for each player. And when player connects I should check if there any changes already; if it is then send right away; if it isn't then listen for 'change' event and then send. In the end code looks so awkward and hard to understand and I don't know how to make it right. There is socket.io which should make things better on the server side but again no iOS SDK for client.
I don't know where to go from here. Any help would be very appreciated.
Turn based architectures are actually not too complicated as lag is really not a huge concern, and data is not being sent constantly.
I would create two web services, one for matchmaking and another to handle the actual game.
The matchmaking would simply queue up players, when there were enough for a match, the service would pick a group of players and assign them a sessionID and pass the players to the game service.
For the game service, it is important to differentiate what can be handled on the client and the service.
The game service would store all game information for each sessionID including clients. This would allow a single service to manage hundreds of games at once with ease. When a player answered a question it would send that in a request to the server with the sessionID. The server would iterate over the clients in the session and send the information to them.
The client could handle hiding questions until the user has answered. (You could even encrypt the other question information if you were concerned about hacking).
The server would also track the timer for the session, when the timer expired it would send a response to all the clients, as well as ignore any later answers. A round integer could be stored in the session, and wrapped in communication with sessionID so as to differentiate answers to past questions. You could have a timer for prediction on the client, but the server needs to be the authority over the timer to avoid cheating.
Use secure ssl https protocols using your own auth tokens to keep the cheaters out.
The client would need to keep track of time span for each player not the actual time. The individual times spans are sent to the server after the round ends on each client.
Think of it like this. There are 3 clients, all polling a server as when they start the round. Because the three could have varying network speeds you don't know who will actually start first. So when each client finally receives the green light then the timer starts for that device, on that device at that time it is received on that client device. You wait until all 3 report back to the server with their time spans to determine who won the round.
There as some topics of concern out of the logic of just the game. Here are some examples.
User Identity and Authorizing. (Game Center)
Game Data Persistence and Storage. (Cloud Database like AWS DynamoDB)
Game Match Queuing. (AWS SQS) Don't attempt this with a database using pessimistic concurrency.
Notifications of Match Players are ready for sleeping clients. (AWS SNS to APNS to Endpoint(this mobile device))
Polling or Notification for Next Move. (AWS SQS or SNS) I wouldn't poll the Database.
Those services are just example recommendations. I don't work for Amazon, they are the easiest to get up and running but there maybe better services out there.
Basically what I am getting at you are going to want more than a traditional MySQL database on some basic hosting site. Some of these cloud services have become very affordable as compared to creating all the infrastructure yourself on dedicated servers.
The are exponentially more scalable also.
You could do all that listed above to start out for under $15 a month using cloud services. The best thing is if your idea takes off you simply bump up the thresholds on those with a flick of a switch from an admin portal.
That would be a good problem to have.
I'm currently designing an application for iOS (using MonoTouch) that will have a server component running on Windows Azure. The application will essentially be a chat type application where users will generate messages within their clients and send them to the server, which will then need to forward those messages out (as quickly as practicable) to other clients that the user might be sending the messages to.
My question is - is there a recommended practice for architecting an application like this, where clients need to receive 'push' messages from the server?
I've considered a few options but would appreciate feedback.
The first option is to use Apple's Push Notifications service (APNs). I have two concerns about this - first, the clients only need to receive the messages when they're online (APNs sends messages through when the app is closed too, which I don't need or want); and second, there is a possibility that there will be a high volume of messages, which I know Apple would probably get unhappy about (perfectly fairly).
A second option I considered is using a web service (WCF-based) and having the client call this service every (say) 2-3 seconds, which is the maximum delay we could tolerate. This would seem to involve a great deal of potentially unnecessary network traffic, though ("have you got anything for me?", "no", repeated ad nauseum).
A third option is to maintain a persistent web service connection between the client and the server. When the client app starts it would call a web service method on a background thread. The server would hold the connection open (by not returning anything), and if any messages came through it would immediately return them. This connection might time out after, say, 2 minutes at which point it would be re-established. This seems to do what I want, but again, I'm concerned that there'd be a lot of connections open to the server at any moment, which could require server resources unnecessarily.
A fourth option is to use a persistent connection over TCP (or UDP, although from what I've found, Windows Azure doesn't support this). This seems to be a good option, but again, might be overkill in terms of server usage - there could potentially be hundreds or even thousands of clients connected at any moment.
A fifth option is to somehow have the server push messages directly to the client, perhaps by having the client run a mini web server or similar. However, as the app will be running on 3G and WiFi networks (beyond my control) I don't expect incoming ports will be open for this sort of thing.
If anyone has any other suggestions, or thinks one of the above options would be a good idea (or is a standard way of approaching this sort of problem) I'd be very interested to hear about it.
Thanks in advance,
John
You had a look at Pubnub http://www.pubnub.com/ ?
I have heard that web-based chat clients tend to use networking frameworks such as the twisted framework.
But would it be possible to build a web-based chat client without a networking framework - using only ajax connections?
I would like to build a session-based one-to-one web chat client that uses sessions to indicate when a chat has ended. Would this be possible in Rails using only ajax and without a networking framework?
What effect does it have to use a networking framework and what impact would it have on my app to not use one? Also any general recommendations for approaching this project would be appreciated.
If i understand you correctly, you want to have to clients connect to you server and send messaged to each other to each other through ajax, via the server.
This is possible, there are two approaches to do this.
The easy approach is to have both client poll every few seconds to check for new messages posted by the other. Drawback is that the messages are not instantly delivered. I think this is an example found in the rails book.
The more complex approach is to keep an open connection and sent the messages to the client as soon as they are received by the server. To do this you can use something like Juggernaut
I would like to add that though the latter works, it is not something http was meant for and it a bit of hack, but hey, whatever gets the job done. A working example of this is the rails chat project which uses a juggernaut derivative.
Technically speaking every network based application has a networking framework under it and, therefore, is socket based...
The only real question here is whether you want to have all that chatter go through your server or allow point to point communication. If the former, you can use the ajax framework to talk to your web server. This means that all of your clients will be constantly polling the web server for updates.
If the later, then you have to allow direct tcp connections between the two clients and need to get a little closer to the metal so to speak.
So, ask yourself this: Do you want to pay for the traffic costs AND have potential liability over divulging whatever it is that people might be typing into their client; or, would you rather just build a chat program that people can use to talk to each other?
Of course, before even going that far, do you really want to build yet another chat client? That space is already pretty crowded.