How WhatsApp works?

Question

I am currently learning about web programming. I started to learn more about internet protocols and other internet applications.

I just wanna understand how WhatsApp works? It's using XMPP and just a code to communicate with the server. But what's happening in the background?

How is WhatsApp speaking with the server? What is WhatsApp's XMPP server IP? What type of format using that app when communicating with the server? And why nobody can use it directly on pc? If WhatsApp is a communication software it means I can communicate with the server from any device or any os right? But I couldn't found any example about it.

And finally, after I signed up on WhatsApp with my phone number for the first time it sends me an SMS and does verification. But after this how does WhatsApp recognizing me? From my mac address? Or from any other special key?

What happens if that recognizing key or mac address is the same in two different devices with two different IP addresses? Can the server understand it? Will one of them took the message or both?

Answer 1

WhatsApp or most of the other messaging apps rarely work on a peer-to-peer basis. So it wouldn't open a connection (from your device) to each of your friends' devices. Instead, your device connects to their server. It could then use a custom TCP protocol or maybe HTTP to communicate your messages to the server. The server in return would dispatch them to your friends' devices. If your friend had their app open or at least the app process running then there might be a live connection to the server. WhatsApp will use that connection to send them your messages. If their app is "offline" then they might choose to send them a push notification instead.

WhatsApp has chosen Erlang a language built for writing scalable applications that are designed to withstand errors. Erlang uses an abstraction called the Actor model for its concurrency instead of the more traditional shared-memory approach, actors communicate by sending each other messages. Actors unlike threads are designed to be lightweight. Actors could be on the same machine or on different machines and the message passing abstractions works for both. A simple implementation of WhatsApp could be: Each user/device is represented as an actor. This actor is responsible for handling the inbox of the user, how it gets serialized to disk, the messages that the user sends, and the messages that the user receives. Let's assume that Alice and Bob are friends on WhatsApp. So there is an Alice actor and a Bob actor.

Let's trace a series of messages flowing back and forth: Alice decides to message Bob. Alice's phone establishes a connection to the WhatsApp server and it is established that this connection is definitely from Alice's phone. Alice now sends via TCP the following message: "For Bob: A giant monster is attacking the Golden Gate Bridge". One of the WhatsApp front-end servers deserializes this message and delivers this message to the actor called Alice.

Alice the actor decides to serialize this and store it in a file called "Alice's Sent Messages", stored on a replicated file system to prevent data loss due to unpredictable monster rampage. Alice the actor then decides to forward this message to Bob the actor by passing it a message "Msg1 from Alice: A giant monster is attacking the Golden Gate Bridge". Alice the actor can retry with exponential back-off till Bob the actor acknowledges receiving the message.

Bob the actor eventually receives the message from (2) and decides to store this message in a file called "Bob's Inbox". Once it has stored this message durably; Bob the actor will acknowledge receiving the message by sending Alice the actor a message of its own saying "I received Msg1". Alice the actor can now stop its retry efforts. Bob the actor then checks to see if Bob's phone has an active connection to the server. It does, so Bob the actor streams this message to the device via TCP. Bob sees this message and replies with "For Alice: Let's create giant robots to fight them". This is now received by Bob the actor as outlined in Step 1. Bob the actor then repeats steps 2 and 3 to make sure Alice eventually receives the idea that will save mankind.

WhatsApp actually uses the XMPP protocol instead of the vastly superior protocol that I outlined above, but you get the point.

For your own application things to consider: You might not have control over clients sending GPS coordinates to the server every 10 minutes. If your client is running on a mobile device, the OS might decide to starve you from resources or just kill your process. You need to maintain a state for clients that are connected to your server to make sure you can send messages to active clients when your requirements are met. This is a slight modification of the stock "Comet app" example that almost every framework has. Establishing a TCP connection is not a very big waste of resources either from the client's side or from the server's side. If your server software ecosystem supports nonblocking IO, the state required per connection is tiny. You could support upwards of 100k connections on a mediocre box if you tried hard. If you are on the JVM Netty might help you here. Python has Twisted and Tornado. C++/ C can make use of epoll, kqueue or select if you are on a *NIX system. Golang supports a high number of connections through its standard library. We have addressed vertical scalability here i.e. how many users could you support on a simple box. If you really want to scale out and build a distributed system that maintains state, you might want to consider Erlang (with OTP) or other implementations of the Actor model, like Akka (JVM) which also supports remote messages. A combination of event sourcing and a message passing architecture could get you all horizontal scalability you need.