I'm trying to create a queue system in NodeJS so that only 20 connections are able to access a certain page at once. Right now I'm assigning each user a unique ID using shortid and javascript localStorage (to store their ID). I want to give each user 1 minute to see the piece of content and then it boots them to "get back in line". If they have to wait it will tell them "You'll be connected in XX minutes".
Right now my process is to use http.globalAgent.maxSockets = 20; to only allow 20 people in but it's not allowing me to route them somewhere else to make them wait. My thought was to have a database of what order people are "in line". Then when a user is kicked off the page after 1 minute, the next user "in line" will be brought in and given 1 minute before they are kicked out.
I'm using MySQL to store the queue. The problem is I'm not sure how to finish the code to boot someone after one minute and make them "get back in line". Any help? Thanks!
I think you're misunderstanding the HTTP protocol. When you make an HTTP request, a TCP connection is created, but not held. You also cannot just limit the sockets for a single route. HTTP is not a persistent connection. You'll need to find another way to implement such a system. Being that HTTP is stateless and non-persistent it will be difficult to do correctly. So if you limit your maxSockets to 20, that means that you can only accept 20 requests at a time. A socket is created for a request/response, but does not persist after that even if the user is still views the page.
You'd probably need a way to "check-in" a user to that page. Something that comes to mind would be to have the users connect to a web socket when they reach that page, and each time a user attempts to join then send out a broadcast to all the users on that page to see how many are still on it. This would still be easily fooled unless you served the pages content over the websocket, because I could simple disable websockets or load a script to just disconnect from the websocket so it cannot "put me back in line". It's likely a very complicated solution, because you're trying to manage the state of your clients, and that's not something HTTP is good at on its own.
Related
Looking for some help with a problem i am facing, I am working on a project where we have a page that contains buttons with statuses, for example full, empty, half-full etc, These are designed to show that status of trucks as they pass through several systems, as they do, 1 of many people can select a button and it should update on all screens.
So something like this.
Truck enters stage one, user clicks button on stage one section of the page and that is then displayed to everyone who views the site on the internet.
I have no code at the moment as it is still be planned out.
I am stumped on the best way to achieve this, so any help at all would be appreciated.
Thanks
Edit: Alternately, use WebSockets, which solves the issue I describe below by allowing server and client to interact two-ways. Have a link!
Think of a web application in terms of server and client. The server cannot send requests; only the client can send requests to the server, which can respond to these requests.
In your application, the server should at all times keep track of the state of all buttons (e.g. whether they are pressed or not). Whenever a client presses a button, it sends a request to the server, which now knows to change the state.
The problem now is sending this new state to all of the other clients. Since the server can only respond to requests, not initiate them, that means all of our other clients must be waiting on a response from the server at all times.
Thus, the solution is to have each client constantly have an unanswered request to the server. Whenever the server responds, immediately send back another request (anticipating the next state change).
Tangentially: this is how many real-time chat applications work, including Facebook chat. If you open the developer tools on your console, you can actually see your browser sending and waiting on requests.
This question isn't a code-level issue but merely a functionality question / brainstorm.
Within my PHP script I want to send a notification to another user in real time, there's 1 way I've thought of to do this, if you know any better ones be sure to leave them in the comments!
My idea for this functionality is to insert into a databse table with the user's id and the message, then on the user's end constantly loop a select request looking for notifications corresponding to their id within $_SESSION, if it's found a message then delete it from the table and display it to the user.
This seems like it could "strain" my database and I'm wondering if there's a cleaner way to do this, it would also be much appreciated if somebody could post a javascript loop with a 3 second delay and an ajax post to a php file within it,
Thanks all,
James
The cleaner way to do this would be with websockets. Polling, long polling, and streaming are going to have exactly the problem you thought you were going to have.
The message recipient needs to be listening via broadcast also through websockets. The server will notify all websockets listening for that particular event.
You don't want to block with database read and writes. Just take the action from one user and send it to all the other websockets listening for that event (the other user's client side instances)
For event history you would consider persisting to a database with a message queue.
With a properly indexed, well-structured table, it won't be a strain to the db at all. Of course, this assumes your interval is reasonable (3 seconds you mentioned is great). That's how all real-time session-checking websites work. Those that need more than that, such as chat systems, basically anything that passes data more frequently and/or in larger packets, they use websockets.
Use Websockets or Server-Sent-Events
just an idea:
User-1 send message to the Server {"message" : "hello", "target" : "User-2"}
Server checks the message and redirect it to the target User
User-2 listening for events from Websocket or Server-Sent-Events
I'm coding a translation system for multiple messages.
I've a page with a table listing all the messages that need to be translated. When a translator click on a message to translate it, I lock it cause no other translator can be assigned to it.
The problem arises when a translator enters and instead to write something, leaves the page in an unconventional way like back button or closing the browser.
If this happens I want to unlock the message to make it available again to other translators.
How can I reach this behavior?
I know the javascript onbeforeunload event but triggers also every time a user refresh the page and this isn't what I want.
ty in advance
EDIT:
seems that implementing a js ajax call to notify every minute the server is the way to go. Now the question is how to handle the PHP server side?
You can use WebSockets, but in my opinion its a immature technology and still away from being firewall friendly.1
So, you can use HTTP polling. Use a JavaScript to make a HTTP request to the server from time to time, so it will show to the server the client is still in the page. The time will depend on connection, number of user's etc, but putting it before the keep-alive expires is a good idea as the TCP/IP connection is still open.
If the user leaves the page, the polling will not execute, and after not receiving the HTTP request for x seconds plus some time, the server can assume the user is not more on the page.
1 - Well its the firewall that is not friendly of WebSockets, this probably will change with time
What's wrong with using onbeforunload and asking the person if they really want to leave the page with unsaved changes?
I'd use the mentioned approach while proving a manual save button.
Also, a timeout on locks would help, so if the person has not edited the field for several minutes, it'd be unlocked and the person would be notified via a JS AJAX call.
EDIT: to implement the AJAX timer, I'd do the following:
save last access time to the translation item in a database or in a file on the PHP side
once every 30 seconds, do an AJAX call to a PHP script that will verify the last access time
depending on the result, return an "OK" or "TIMEOUT" message from the PHP script to the JavaScript part, which will then either do nothing (for OK) or deactivate the translation and inform the translation about the timeout
I was tasked to build a calendar and agenda library (I'm working on the CodeIgniter framework), that shows a calendar and the user has the possibility to set events on that calendar.
These events will have a notification system both email, and when the user is browsing the site, a popup.
My issue is how to approach the notification part when the user is on the site. The email is something that I already decided would be done trough a cronjob that will run every x minutes and check if there is any need to send a notification email.
The on site notification is something else.
How would I approach this? I just can't make a ajax request to the server every x seconds, since that would put an unnaceptable load on the system. (Of course when the user is eventually notified, a request must be made, to set the user as "remined" on the database).
I can't just depend on the user's date time, since he could be anywhere in the world and the time would be different.
How can I check that the user must be notified of a event, avoiding making repeated requests to the server? Would appreciate any input.
I could see using setTimeout to do this. Say a user visits your page $minutesTilDue minutes prior the reminder being due. Assuming jQuery/PHP:
$(function(){
setTimeout(function(){
showEventReminder(<?php json_encode($event) ?>);
}, <?php echo $minutesTilDue ?> * 60 * 1000);
});
Nothing too fancy, but depending on your requirements...
Cheers
Easily scalable notification systems use websockets, which today reach the majority of the users, even on mobile devices. Unfortunately, you'll need a websocket-enabled server - node, glassfish, whatever - this can't be done with standard PHP deployments (mod_php or fcgi). Server events (so called server push) are sent when they are generated, so once you have your websocket client-server pair, sending a reminder is just like sending an email.
Actually things are more complicated because most likely users won't be online at the exact time the reminder should pop up. I suggest a notification icon which is refreshed each time the user hits a page. This way your calendar system (suppose a cronjob) will simply update a flag for the user row in the DB, and when you build the page, you already know if there reminders (let's say, in the next 60 minutes) or not, and choose the icon accordingly. At this point, you have two choices:
sending the reminders to the client along with each and every request (it could be a waste of bandwidth, but I don't thing a JSON-encoded list of events is so heavyweight)
Download the reminders asynchronously on demand, ie only when the user hits the notification icon
This scenario lets you reuse the PHP environment and code, and doesn't require another host for the websocket server. I think this is the best solution, even if this doesn't fulfill your requirement of a truly popup reminder triggered by the server at the right time. BTW, if you send events with every request, your javascript can pop up when needed - you can use setTimeout() for this.
I'm building a basic little AJAX shoutbox/chat for my website, but I'm not sure exactly how to implement the server polling.
Here's the basic program flow I'm thinking of:
User comes to page and is shown the last 10 messages
To get messages sent by others, the client javascript would request a URL with a timestamp parameter (set to the value of the last message the client received)
The server returns all messages (up to a max of 10) since that timestamp.
The only issue is how often to poll the server. Obviously it should poll each time a new message is added, but when you're just reading others' messages it needs to automatically update.
Should it be a set time limit? eg: every 10 seconds. Or, should it vary depending on usage? eg: Check after 5 seconds. If there's no messages, don't check for another 10 seconds. If there's still no new messages, check in 15 seconds, then 20, up to maybe once every 30 seconds max. Each time there's a new message detected reset your timer back down to 5 seconds and start again.
I'm just concerned about putting unnecessary stress on the server, considering that we could have hundreds of users concurrently online.
...or have I got the whole thing wrong? Is there a better way to implement a basic javascript chat?
You might want to look into what are known as Comet programming techniques to stream information down to your users, rather than having the client poll the server. This is actually a family of techniques, some of which may work better than others depending on the circumstances, such as what kind of server you're using and what kind of client compatibility you need.
If your server can handle a large number of open connections at a time (as in, it does not use an entire thread or process per connection, such as nginx or an erlang based server), you may wish to use a long polling technique, where as soon one message is received, the client immediately requests another message. If there are no messages available, the server simply keeps the connection open, possibly sending occasionally dummy data as a keepalive, until a message becomes available.
Comet, described by Brian is a nice technique, but requires session support on the server, which is probably more advanced than you care to implement for a simple chat box.
The best way to implement polling intervals is to imagine you having a chat window which you can minimize to do other stuff, or open to see if you have new messages. When you are in the middle of a conversation, you'll switch to it (poll) frequently. If you don't get any messages for a while, you will start looking rarer and rarer until you only check it occasionally.
Assuming you don't need to do real-time typing, you can probably poll every 3 seconds or so when at peak activity, and if nothing shows up for 5-10 polls, start to crank the interval up (perhaps doubling it every time) until it hits 30-60 seconds. Getting a message back should reset the poll interval back to a few seconds, while sending a message should poll instantly, but probably doesn't need to effect the frequency of polling otherwise.
Honestly, if you are implementing a “basic little AJAX shoutbox/chat”, things like Jabber, Comet etc are overkill for you. These things will require you to run additional
servers/proxies to take the load of the app server and db.
When you think about stuff like presence management (“Joe is typing...”), then things get overly complex for your app (considering “chat” is not your prime focus).
Think about adding widgets from providers like Meebo and Userplane. Once you scale think about the Jabber and the like…
You should check to see if the other user is typing every 5 seconds or so, if the other user is typing, then you can check every 1 second to see if the user has sent a new message. Really though, you should be able to check every 1 second to see if other user is typing and if they are then every .25-.5 second check to see if new message has been sent. With broadband being so generally accepted on the inet, shouldn't be a problem. Go with the longer poll timeout for a dial-up access.
This is a very hard question, keep abuse in mind. Malicious users will hit you as often as possible, with the earliest timestamp faked so as to cause stress on your DB server. Be sure to validate that timestamp, or ignore it, because shouldnt everyone be in the same time anyway?
You can send the polling interval to the user as a function of the other user's response time. That's the best kind of dynamic I think.
http://jabbify.com/home/comet_service
This is a free comet based chat service by the guys who did the jmvc framework. Haven't tried it yet, but looks promising.
The professional way of doing this is with a WebSocket javascript connection. You can use a free service like https://socketsbay.com/ for example, and connect using
// Create WebSocket connection.
const socket = new WebSocket('wss://socketsbay.com/wss/v2/[ChannelId]/[ApiKey]/');
// Connection opened
socket.addEventListener('open', function (event) {
socket.send('Hello Server!');
});
// Listen for messages
socket.addEventListener('message', function (event) {
console.log('Message from server ', event.data);
});
You can forget about server pooling time because it will be realtime.