HN user

hungnv

-2 karma

tiny techie.

Posts4
Comments11
View on HN

This is practical implementation when working with websocket. When server got an error or timeout waiting for client pong, it closes the connection, at the same time client send “health check” message without receive reponse (whatever message value of your choise) it closes the connection and reconnect.

Come to think of it, I searched and didn't find a "distributed disk cache with optional replication" that can be used in front of S3 or whatever dataset. You can use nginx/varnish as a reverse-proxy but it doesn't have "distributed". There is Alluxio, but it's single-master.

If you think more about this, it will be like distributed key value store with support both disk and memory access. You can write one using some opensource Raft libraries, or a possible candidate is Tikv from PingCap

Zig in 30 Minutes 6 years ago

I wish all language as same syntax, no matter whats its implementation, no matter it has cool feature or not. So new comer will get use to it faster.

Why its not int64, int32, unsigned_int32, vec, function for all language, but inventors have to change these to u64, i64, fn...etc?

at first I guess it'd be great, finally eff found a solution that any companies can implement their own security layer that's compliant with new standard and EME, but it's not. Even if W3C accepted this open letter and changed, there would be nothing changed at all.

hello,

Because video encoding is very expensive job, so the idea is to split things into small chunk and encode chunks instead of video file itself.

I can see we can archive smooth streaming and seeking went well in our production (with caching enabled).

It would be great if people can give it a try :).

Thanks!

Most people - who know C or any programming language do not ask for a book to read, just pick one, read it carefully, do something based on it, make mistakes, learn from them. Time went by, write a book!

I had worked for a social network, and our system provides a function to let user upload their photo then transform it to some fixed size of original one. We did have pre-transformed and on-demand too. Pre-transformed for the image that's most viewed by user, like new feed's photo (720x720), large photo (1024x768), and the origin one (if user's screen is detected as big screen), we have to resize it asap. Other sizes, like thumbnail, we do on-demand transform using nginx resize filter plugins, and caching using varnish and/or traffic server. That system have been working well until this time. I would say on-demand transformation is good idea, since you don't have to store resized-image that's never viewed by any user, so you save your storage. But that idea must be implemented well, very well if you're going to serve million users.