I have got an issue with Room join & Inviting members to XMPP Room in iOS.
I have a clause that needs to join 200 rooms together at login, I did it but it blocks the main thread.
Can anyone suggest the Approach to handle hundreds of room joining seemless without blocking main thread.
Thanks,
Why did you join 200 rooms at a time in the first place?
My guess you need to join so that be able to get all group chats? This is a very inefficient way. I think you need to implement Offline Message Push Notification.
Look into ejabberd_mod_offline_post
First config the Room must be a Member-Only room, and add all users as members right after you created it, so that be able to get a total.
Add above model into ejabberd models.
Implement a Callback Service to handle the callback post.
The idea is when User go offline:
In one-to-one case, offline_message_hook will be raised
In MUC case, muc_filter_message will be raised, and any one not Presence-Available is offline.
Related
for an endpoint that assigns jobs to employees, I would like the requests to the endpoint to be processed sequentially so that it is not possible for multiple employees to sign up for a job.
Is there a way to do this ? Or maybe even something better ? How does this work on shopping sites with carts ? These often also need to check first if the product is available and prevent two users from buying the last product.
Thanks a lot!
I want an admin account to send an announcement to all users in the db.
Right now for my Message table I am storing a message every time for user to user messages with senderId and receiverId etc.
My problem is can I treat announcement the same way as user to user messages and if yes, would it be wise to save into the message table n times for n number of users in the db every time there is an announcement?
So I want to see if there are cleaner approach to this.
It depends on how much time/effort you want to invest in this.
Separate table for announcements: You won't be able to reuse your current messaging system, but you will have maximum flexibility (special GUI features for announcements, they won't get mixed up with normal messages, etc.)
Modify your current messaging system to support multi-recipient and/or broadcast messages. With this you can reuse most of your current GUI with some backend modifications.
Do the simplest possible thing and send a message to everyone. This is very easy to implement. The obvious downside is that you will have a lot of copied messages in your DB, which may or may not be a problem.
I need to architect a database and service, I have resource that I need to deliver to the users. And the delivery takes some time or requires user to do some more job.
These are the tables I store information into.
Table - Description
_______________________
R - to store resources
RESERVE - to reserve requested resources
HACK - to track some requests that couldn`t be made with my client application (statistics)
FAIL - to track requests that can`t be resolved, but the user isn't guilty (statistics)
SUCCESS - to track successfully delivery (statistics)
The first step when a user requests resouce
IF (condition1 is true - user have the right to request resource) THEN
IF (i've successfully RESERVE-d resource and commited the transaction) THEN
nothing to do more
ELSE
save request into FAIL
ELSE
save request into HACK
Then the second step
IF (condition2 is true - user done his job and requests the reserved resource) THEN
IF (the resource delivered successfully) THEN
save request into SUCCESS
ELSE
save request into FAIL
depending on application logic move resource from RESERVE to R or not
ELSE
save request into HACK, contact to the user,
if this is really a hacker move resource from RESERVE to R
This is how I think to implement the system. I've stored transactions into the procedures. But the main application logic, where I decide which procedure to call are done in the application/service layer.
Am I on a right way, is such code division between the db and the service layers normal? Your experienced opinions are very important.
Clarifying and answering to RecentCoin's questions.
The difference between the HACK and FAIL tables are that I store more information in the HACK table, like user IP and XFF. I`m not going to penalize each user that appeared in that table. There can be 2 reasons that a user(request) is tracked as a hack. The first is that I have a bug (mainly in the client app) and this will help me to fix them. The second is that someone does manually requests, and tries to bypass the rules. If he tries 'harder' I'll be able to take some precautions.
The separation of the reserve and the success tables has these reasons.
2.1. I use reserve table in some transactions and queries without using the success table, so I can lock them separately.
2.2. The data stored in success will not slow down my queries, wile I'm querying the reserve table.
2.3. The success table is kind of a log for statistics, that I can delete or move to other database for future analyse.
2.4. I delete the rows from the reserve after I move them to the success table. So I can evaluate approximately the max rows count in that table, because I have max limit for reservations for each user.
The points 2.3 and 2.4 could be achieved too by keeping in one table.
So are the reasons 2.1 and 2.2 enough good to keep the data separately?
The resource "delivered successfully" mean that the admin and the service are done everything they could do successfully, if they couldn't then the reservation fails
4 and 6. The restrictions and right are simple, they are like city and country restrictions, The users are 'flat', don't have any roles or hierarchy.
I have some tables to store users and their information. I don't have LDAP or AD.
You're going in the right direction, but there are some other things that need to be more clearly thought out.
You're going to have to define what constitutes a "hack" vs a "fail". Especially with new systems, users get confused and it's pretty easy for them to make honest mistakes. This seems like something you want to penalize them for in some fashion so I'd be extremely careful with this.
You will want to consider having "reserve" and "success" be equivalent. Why store the same record twice? You should have a really compelling reason do that.
You will need to define "delivered successfully" since that could be anything from an entry in a calendar to getting more pens and post notes.
You will want to define your resources as well as which user(s) have rights to them. For example, you may have a conference room that only managers are allowed to book, but you might want to include the managers' administrative assistants in that list since they would be booking the room for the manager(s).
Do you have a database of users? LDAP or Active Directory or will you need to create all of that yourself? If you do have LDAP or AD, can use something like SAML?
6.You are going to want to consider how you want to assign those rights. Will they be group based where group membership confers the rights to reserve, request, or use a given thing? For example, you may only want architects printing to the large format printer.
I'm working on a SNS like mobile app project, where users upload their contents and can see updates of their subscribed topic or friends on their homepage.
I store user contents in mysql, and query the user specific homepage data by simply querying out first who and what the user subscribed and then query the content table filtering out using the 'where userid IN (....) or topic IN (....)' clause.
I suspect this would become quite slow when the content table piles up or when a user subscribe tons of users or topics. Our newly released app is already starting to have thousands of new users each week, and getting more over time. Scalability must be a concern for us right now.
So I wonder how Facebook or Twitter handle this subscribing problem with their amazing number of users. Do they handle a list for each user? I tried to search, but all I got is how to interact with Facebook or Twitter rather than how they actually implement this feature.
I noticed that you see only updates rather than history in your feed when using Facebook. Which means that subscribing a new user won't dump lots out dated content into your feed as how it would be by using my current method.
How do Facebook design their database and how did they dispatch new contents to subscribed users?
My backend is currently PHP+MySQL, and I don't mind introducing other backend technologies such as Redis or JMS and stuff if that's the way it should be done.
Sounds like you guys are still in a pretty early stage. There are N-number of ways to solve this, all depending on which stage of DAUs you think you'll hit in the near term, how much money you have to spend on hardware, time in your hands to build it, etc.
You can try an interim table that queues up the newly introduced items, its meta-data on what it entails (which topic, friend user_id list, etc.). Then use a queue-consumer system like RabbitMQ/GearMan to manage the consumption of this growing list, and figure out who should process this. Build the queue-consumer program in Scala or a J2EE system like Maven/Tomcat, something that can persist. If you really wanna stick with PHP, build a PHP REST API that can live in php5-fpm's memory, and managed by the FastCGI process manager, and called via a proxy like nginx, initiated by curl calls at an appropriate interval from a cron executed script.
[EDIT] - It's probably better to not use a DB for a queueing system, use a cache server like Redis, it outperforms a DB in many ways and it can persist to disk (lookup RDB and AOF). It's not very fault tolerant in case the job fails all of a sudden, you might lose a job record. Most likely you won't care on these crash edge cases. Also lookup php-resque!
To prep for the SNS to go out efficiently, I'm assuming you're already de-normalizing the tables. I'd imagine a "user_topic" table with the topic mapped to users who subscribed to them. Create another table "notification_metadata" describing where users prefer receiving notifications (SMS/push/email/in-app notification), and the meta-data needed to push to those channels (mobile client approval keys for APNS/GCM, email addresses, user auth-tokens). Use JSON blobs for the two fields in notification_metadata, so each user will have a single row. This saves I/O hits on the DB.
Use user_id as your primary key for "notification_meta" and user_id + topic_id as PK for "user_topic". DO NOT add an auto-increment "id" field for either, it's pretty useless in this use case (takes up space, CPU, index memory, etc). If both fields are in the PK, queries on user_topic will be all from memory, and the only disk hit is on "notification_meta" during the JOIN.
So if a user subscribes to 2 topics, there'll be two entries in "user_topic", and each user will always have a single row in "notification_meta"
There are more ways to scale, like dynamically creating a new table for each new topic, sharding to different MySQL instances based on user_id, partitioning, etc. There's N-ways to scale, especially in MySQL. Good luck!
We have website with articles users can vote for. What is the recommended method of limiting votes?
There are so many sites that have voting implemented that I know some possible solutions but I guess that is some basic bulletproof recommended method based on sessions, IPs, time limit, etc.
What is the best way to send votes from browser? Basic GET/POST or AJAX request? Is it necessary to use some pregenerated request-id?
Update: We cannot use user registration.
[...] bulletproof [...]
Impossible.
Limiting by account will help - IP addresses are far to dynamic and easily changeable to be remotely "secure". You then of course have to limit account creation, again, difficult..
Stackoverflow does it quite nicely (there was blog-entry about this recently, "New Question / Answer Rate Limits") - basically have accounts where you have to actively participate for a while before you can vote. Then you are rate-limited (by account) until you've participated for a bit longer. Then the limits are removed, so you don't annoy more active (more trusted) users.
If you just want to prevent causal, "accidental" voting, limit by cookie, and possibly also by IP (bearing in mind more than one user can be behind a single IP).. If you want to try and prevent abuse, require accounts which you can't just click "signup" for (or rather, one you cannot write a "click signup 2000 times"-script for), although this isn't always possible (or practical)
The best way of preventing duplicate posts is having only signed in users vote. That way you can store their vote in some data storage (DB).
If you want to allow for users to vote anonymously, use the browser session.
The downside of this is that they can just close/reopen the browser and revote.
I would not recommend using IP for restricting votes, since many users can be behind a proxy, so it will look like they have the same IP. If one of those users vote, the others could not vote anymore.
This may help for your bulletprof recommendation request : Content Voting Database and Application Design
There's no bulletproof solution unless you require some serious (banking level) authentication. That said, the basic solution is to use sessions (cookies). IP limiting is a very bad idea (for example I'm sharing an IP with about 20 other people).
Use authenticated users
Don't block IP
Don't verify votes by cookies
Try to use captcha if same IP is voting multiple times with different accounts
If you want to allow non authenticated users, then you're sure to have to use captcha to avoid bots. But still i think that the best is to allow vote to authenticated users only.
You can make something like, a user younger than 1h/2h can't vote to avoid bots creating accounts and feeding votes.
The best approach should be by user_id, one user can only vote one time on each challenge, each challenge should have an unique ID.
Allow new users to register.
Check if user is authenticated.
Check if user already voted in challenge ID, before creating a new vote.