4 ms·

I found the concept of affinity used for bunching messages to be a new concept. The other concepts are not surprising, they are the typical engineering solution

by sn41 8y ago

I found the concept of affinity used for bunching messages to be a new concept. The other concepts are not surprising, they are the typical engineering solutions used. One thing I am curious about: how does it compare to how the old postal systems used to handle Christmas and new year loads? On a lighter note: perhaps you can predictively generate and cache messages at the receiver's end based on their contacts and their style of communication. When a sender actually sends a message, just send one bit across, and the local cache gets flushed and displayed :)

kaustyap 8y ago
It may be a good idea to provide range of fixed templates for standard messages and send just selective message Id along with recipient name over the network.
zimpenfish 8y ago
> I found the concept of affinity used for bunching messages to be a new concept. I'm reasonably sure that UUCP + things like INN were "batching messages per destination" for efficiency a long time ago. Nowhere near the same scale, obviously, but the same kind of concept, no?
- Jedd 8y ago
  Actually, I'd expect the scale would be similar. The raw numbers (users, bandwidth, latency) would be quite different.
ehsankia 8y ago
take the 16 most common messages, normalize them a bit, and encode them in 4 bit, and I would guess that would probably cover over 50% of the messages sent, maybe even close to 80%.
- fhrow4484 8y ago
  While it's a nice compression technique, I doubt you'd gain anything from this at the message level. Even by reducing a message content to close to 0 bits, I doubt you would get that much gains. Most common messages would probably be things like "lol" or an emoji, which in utf-8 is 24 to 32 bits. But There'll always be metadata associated with each message: message id, sender, receiver, timestamps, etc. which are unremovable. If those first 3 are typical GUIDs, this is already 3*128 bits. This will put a minimum on the entire message size , and more importantly the processing time to simply route the messages is what is costly in terms of CPU time. Then there's the different receipts mentioned in the article, adding a lot more traffic.
  - babuskov 8y ago
    > If those first 3 are typical GUIDs, this is already 3*128 bits Facebook user ID's are 64bit and I doubt that the message ID needs more than 64bit either. Timestamp is typically 8 bytes, so 64 bits as well. So, you're looking at 256 bits of message header.

by sn41 8y ago

kaustyap 8y ago

It may be a good idea to provide range of fixed templates for standard messages and send just selective message Id along with recipient name over the network.

zimpenfish 8y ago

> I found the concept of affinity used for bunching messages to be a new concept. I'm reasonably sure that UUCP + things like INN were "batching messages per destination" for efficiency a long time ago. Nowhere near the same scale, obviously, but the same kind of concept, no?

Jedd 8y ago
Actually, I'd expect the scale would be similar. The raw numbers (users, bandwidth, latency) would be quite different.

ehsankia 8y ago

take the 16 most common messages, normalize them a bit, and encode them in 4 bit, and I would guess that would probably cover over 50% of the messages sent, maybe even close to 80%.

fhrow4484 8y ago
While it's a nice compression technique, I doubt you'd gain anything from this at the message level. Even by reducing a message content to close to 0 bits, I doubt you would get that much gains. Most common messages would probably be things like "lol" or an emoji, which in utf-8 is 24 to 32 bits. But There'll always be metadata associated with each message: message id, sender, receiver, timestamps, etc. which are unremovable. If those first 3 are typical GUIDs, this is already 3*128 bits. This will put a minimum on the entire message size , and more importantly the processing time to simply route the messages is what is costly in terms of CPU time. Then there's the different receipts mentioned in the article, adding a lot more traffic.
- babuskov 8y ago
  > If those first 3 are typical GUIDs, this is already 3*128 bits Facebook user ID's are 64bit and I doubt that the message ID needs more than 64bit either. Timestamp is typically 8 bytes, so 64 bits as well. So, you're looking at 256 bits of message header.