Hacker News Reader

Comment by karamanolev | Hacker News Reader

I fail to see how TCP/IP fragmentation really affects this use case. I don't know why it's mentioned and given that there aren't multiple network devices with different MTUs it will cause issues. Am I right? Is that the lack of technical knowledge you're referring to or am I missing something?

View on HN

Sounds weird that apparently they expected to send 3 MB in a single TCP packet

Modern NICs will do that for you via a feature called TSO -- TCP Segmentation Offload.

More shocking to me is that anyone would attempt to run network throughput oriented software inside of Chromium. Look at what Cloudflare and Netflix do to get an idea what direction they should really be headed in.

They use Chromium (or any other browser) not out of choice but because they have to in order to participate in third party video conference sessions. Of course it’s best to reverse engineer the video conferencing clients and do HTTP requests directly without a headless browser, but I presume they’ve tried that and it’s very difficult, not to mention prone to breaking at any moment.

What’s surprising to me is they can’t access the compressed video on the wire and have to send decoded raw video. But presumably they’ve thought about that too.

I'm assuming it's because the compressed video on the wire is encrypted?

Especially considering there are no packets in TCP.

There are no packets on the user's API. But under the hood everything is sent in packets, numbered, ACK'ed and checksumed. The maximum packet size supported by IP is 64KB, as they say. I'm surprised the kernel supports that because I'm not aware of any real device that supports packets that big (Ethernet Jumbo Frames are only 9KB), but I guess it must.

Reply on news.ycombinator.com