Chat OR Instant Messenger required

The functionality needed which will allow to transmit an instant message from one peer to the other through the server. The Client’s side of the app must be on Angular Js, whereas the server part must be developed with the help of the following: php, mongodb, redis and nodejs. A detailed description of the process is as follows: a user has a list of friends and for each of those friends the user may have a dialog the user opens a dialog and can see the last 50 (most recent) messages the user can send a reply to the sender when a new message is received it gets placed onto the end of the list If a user is browsing a list of friends and receives a new message from a friend, a red dot (i.e. badge) has to appear next to the friend who sends the message. Since it’s considered a new message, the entire dialog between the user and the friend has to be placed on top of the list. As a result, all the friends are sorted on the basis of when a message is received – new are always on top of the list. If there is at least one unread message from a friend, the friend’s profile has to have a red dot next to their name. If all dialogs are marked as being read, the badge, informing the user of the new message, should be removed. Similarly, upon opening a dialog that has a new message, the red dot has to vanish. Only the first 50 friends are shown on the list at a time, however, if there are more than 50 friends, a user should have the ability to load up another 50 friends etc. When a new message is received from a friend who is not currently on the list, their profile has to move up to the top of the list. When dialogs get automatically removed from the server, the Client’s side must be notified of the need to refresh the screens/data so that the user always stays up-to-date. In those instances when a user may have multiple windows open for the same account (e.g. different devices), any changes made have to be saved and synchronised on all windows/devises immediately. In addition to the above, the system must have the ability to sustain heavy workloads. Despite a number of active users/messages, it has to run smoothly and efficiently. The ‘short-poll’ technique cannot be used due to the inefficiency of the Client’s side needing to send a request in order to check for an update. This method will inevitably ‘flood’ the system with many constant, repetitive and in most cases ‘unnecessary’ requests. Ideally, [login to view URL] or a similar method should be used which will allow to receive an update without compromising on speed. Smiles, delivery status and ‘typing’ mode are not required.