Hacker News Reader

Comment by sn41 | Hacker News Reader

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 :)

View on HN

> 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?

Actually, I'd expect the scale would be similar.

The raw numbers (users, bandwidth, latency) would be quite different.

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%.

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.

> 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.

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.

Reply on news.ycombinator.com