Hacker News Reader

Comment by amelius | Hacker News Reader

FYI, there is a bug in Chrome that causes WebSockets to be slow [1]. For small messages, the transfer rate seems to be sufficient in most cases. But for larger messages (say, uploads), don't place your bets on WebSockets just yet.

[1] https://productforums.google.com/forum/#!msg/chrome/-NVlnMqx...

View on HN

Why would you want to upload a file through websockets anyway?

I made an upload tool that needed to handle very large files, and I used WebSockets to do it.

The strategy I used was to parse the MOV/MP4 locally, consider between 2-60 frames of data, hash it, then stream up the hashes to the server. Any hash the server didn't have got a reply to push those bytes.

The two-way nature of this dialog made WebSockets a good fit, although it certainly could have been emulated using other methods, it would have been much more code.

It seems like it wouldn't be much more code to just use an AJAX POST for the hash and have the server reply whether it has the hash or not, followed by the chunk upload again over AJAX. It would probably be slower and less data efficient, but I don't see how it would be much more code.

The whole point of uploading a file this way is that it is more data efficient and faster in my use case.

That means that slowness is a bug; inefficiency is a bug.

For what reason would you put bugs in your code on purpose?

We also probably have different ideas about how much "much" is.

Perhaps it would require more code to get it equally fast and data efficient :)

One reason is that you have more control over contention over bandwidth. For example, if you have control over the outgoing packets, you can temporarily stop those packets when more important data needs to be sent.

Reply on news.ycombinator.com