I am developing a feature in my app where I need to store the state of a particular series of actions between 2 users, just like an ajax based chat service.
The scenario is as follows:
A user can is able to see which other users are online and then challenge one of them. The other user receives the challenge and accepts it. Now both the users are given 5 questions each and the match starts simultaneously for them (almost simultaneously) Then as a user navigates thru the question or solves it, the state is updated on the other user screen as well.
Essentially this is very similar to a chat system like say facebook chat. I am able to see who all are online. I send a chat msg to my friend who can then respond to that and that response is seen on my chat window.
I believe all this can be achieved by using ajax. I can easily make ajax calls to .asmx webservices and retrieve objects for a particular user as Session can be accessed there. However, I am wondering where to maintain state because session is for a particular user and I want my particular object to be accessible for two particular users.
Where do I store the state? Or taking the example of Ajax based chat, where should I store what message User1 entered and when Uer1 entered how is it shown to user2?
I was thinking application object but read it is not recmmended.
What do you recommend for such a thing?
If you're trying to do "near real-time" message passing you might want to take a look at HTTP polling (a.k.a. long polling). I won't use SQL for temporal message passing and short-term state transitions like I've seen in the past. If running on a single web server just keep the state in session or in the ASP.NET Cache. If running on multiple web servers take a look at distributed caches like memcached, Velocity (Win 2008), or NCache. Then serve the cached data to the AJAX requests which are sitting and waiting (because of long-polling). The key design issue is the design of the cache keys (no pun intended), which would need to include the user's ID for user-specific event data.
P.S. There are frameworks for large-scale, near real-time message distribution that solve scaling issues which are hit when hundreds of clients are participating in long-polling at the same time. The broad name for those frameworks are 'Comet', and they are most useful when broadcasting the same messages to many clients.
Related
I have a User Microservice, that publishes events when a user is created, modified, or deleted. In addition, I have a Calendar Microservice that needs the user data. The Calendar service, subscribes to the user events and keeps a read only copy of the needed data.
I have just added an Account Microservice that needs the existing user data and I have used the same model as above. What is the best way to get the existing user data into the Account Microservice?
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
I've loaded data a lot in the past. I know how to make it work, but I am looking for a best-practice and a way to do it with minimal coordination and dependencies with other services.
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
What you probably want here is a design in which you pull, rather than push, copies of the events to new systems: see Greg Young, Polyglot Data.
In broad strokes - the subscriber keeps track of the high water mark, and asks for more events after some mark, and then the event store answers that query with zero or more new events, in order. The twitter timeline api can give you a sense for how that might work -- sadly, the images that explained the ideas seem to have been removed from the docs, but some of them have been captured here at stack overflow, and by the wayback machine
I had in mind to make a website that pulls data from steam statistics to show how many players are currently playing a specific game. Is this possible or does it have to be an actual api?
If you're planning on this website only ever being a platform that displays the information you're pulling from the Steam API when users access your site, then no, you don't necessarily have to create a public-facing API.
However, if you're creating this application with the idea that other applications are going to programmatically retrieve the data you're displaying on the site, then yes, you should create an API that allows other applications to consume your data.
The best way to do the latter would be to create an independent service that consumes data from the Steam API and transforms it, then makes it available publicly (with authentication if deemed necessary). This API would then be consumed by a client that you create (your website that displays the data) as well as any other application that could make use of the data.
So I want to create some sort of anonymous chat application. The model includes a single server (centralized) and multiple clients.
The server takes no records of the chat and also no records of who has connected amd such to maximise privacy the messages are also encrypted. You get the idea.
Now, my question was: say someone sent a link to a warez site or something deemed somewhat questionable or outright illegal. Who would get into trouble? The server owner or the client? Take into account that the server only provides a means to communicate between clients and holds no information other than the brief time it needs to receive and send.
Same thing with bots connecting to the server and using it for a communication portal for a botnet.
Thanks in advance.
I have a quick question...may sound a little straightforward but still want to throw it out there.
I am aware that typically a session is limited to a single browser and client instance.
With that said though say a user signs up on your mobile device and starts to do some shopping...maybe adds something to their cart and then decides that they want to complete the purchase on their desktop.
I have some people that want to call this a single session while technically its a new session.
Does this make any sense?
In theory this should work with Universal Analytics, at least for logged in users ( I assume that your users are logged in if they want to buy).
You can pass a client id as a parameter when you create the tracker. The client id is supposed to be formatted as UUID, so you'd have to store that along with your real client id in you backend system and pass it in to the tracker as a part of the confuguration json object (optional third parameter in ga create). Apparently this get retroactively applied to the running session (no written source for that but I recently attented a conference where a google employee said as much, so I assume this is legit).
So as far as it concerns data collection UA is ready for multidevice. I frankly do not know to what extent this already works in the Analytics Interface.
I recently had a glimpse at a Analytics Premium Account which already had some new multdevice reports. I don't know if the fact that those reports are, at least for the moment, absent from the free version means that multidevice tracking does not work yet on the free version (those reports are along the line of Venn diagramms for "How many users used more than one device" and the like).
I am trying to create a shared calendar as a web app. When someone adds an event on the calendar i want everyone who shared that calendar to see that event too. When someone create an event, I made an ajax that sends the data to a database. Is there a way to send the event from server to other clients that are online on the page and share the same calendar? I did it now by constantly 'refreshing' the info from database.
If anyone has a clue how this can be made, please tell me.
Wanting a web server to "push" information back to the browser is a time old issue. The traditional way to handle this is to have any active clients (i.e. the people still logged into your app with a page open) continuously "poll" the server at a regular interval to see if there's any new information for it. In your case, you can have some JS on the page make an AJAX call every 10 seconds to see if they have any new calendar events they should be aware of. This does increase the overall traffic to your web server so pick your polling time appropriately - otherwise you'll cripple your web server because it will spend all of its time handling these "is there anything new?" requests when most of the time there won't be.
If you want to be a little more cutting edge, you can look at HTML5 websockets. A google search for "html5 websockets tutorial" should give you plenty of resources. They're a bit trickier to use and require that you are running a web server that supports them (you probably are). For browsers that support it, you can maintain a more long term open connection where you can then push data from the web server back to the browser like you want to and your JS will capture "onmessage" events with the updated info. Pointing you at google isn't trying to flake out of a more complete answer, but there's already a number of excellent tutorials out there so look for HTML websockets and you should be able to pull off what you're looking to do.