Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The curious case of slow downloads

blog.cloudflare.com

Post reply on HN
Print view View original

51–57 of 57 posts

Re: The curious case of slow downloads

#51

Post by jamespo »

lmm wrote: post #50
masklinn wrote: post #17

Earlier quoted context omitted.

> What's that cost? How quickly can it be done? Careful with those goalposts, you're tearing up the pavement. > Companies should reward those who are generous with their code. So companies "should reward those who are generous with their code" but not compensate them for it?

> So companies "should reward those who are generous with their code" but not compensate them for it? No, they absolutely should compensate them for it. Buy OSS.

"So you're asking me to pay for something we can get for free" said every Finance Officer ever...

Re: The curious case of slow downloads

#52

Post by rkangel »

bigethan wrote: post #7

This is why open source (and controlling your whole stack) matters in big business. For example, Microsoft may be changing their image, but their core software is closed source. may be great, but can you pull off something like this when you've got an issue? The importance of being able to debug and patch your mission critical systems is hard to overstate. Please encourage your employer to fiscally support the open s…

There's a different model in this case. You pay for support, and then the original developers go away and fix it for you.

When this works well, it's great. You've got the experts on the problem. Not all support is good though, obviously, and if you have a mission critical problem that you need to fix overnight, nothing beats the 'self-support' that you can do with open source software.

Re: The curious case of slow downloads

#53

Post by arielb1 »

scurvy wrote: post #36
Dylan16807 wrote: post #33

Earlier quoted context omitted.

Well the goal here seems to be aborting a connection, not just closing it. They specifically don't want to empty the buffer, because time is up. Is that a misuse of reset?

Yes, it is a misuse of a TCP reset. The RFCs are very clear about when to use a TCP reset. You can't use a reset just because you want to be fast or don't feel like sending any more data. Resets are for something abnormal happening. A timeout isn't abnormal to a TCP connection. It's part of the process.

Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good.

HTTP does not have a way of sending an error in-mid-transfer, so a TCP reset has to suffice. The other option would be to blackhole the connection, but that would be worse for both sides.

Re: The curious case of slow downloads

#54

Post by nunwuo »

arielb1 wrote: post #53
scurvy wrote: post #36

Earlier quoted context omitted.

Yes, it is a misuse of a TCP reset. The RFCs are very clear about when to use a TCP reset. You can't use a reset just because you want to be fast or don't feel like sending any more data. Resets are for something abnormal happening. A timeout isn't abnormal to a TCP connection. It's part of the process.

Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good. HTTP does not have a way of sending an error in-mid-transfer, so a TCP reset has to suffice. The other option would be to blackhole the connection, but that would be worse for both sides.

> Closing the connection would cause the client to believe that the file has been fully downloaded - resulting in a truncated file. Not good.

That's not correct. Both Content-Length and the chunked encoding scheme would allow the client to know that the connection was terminated before the end of stream was reached.

Re: The curious case of slow downloads

#55

Post by bigethan »

rkangel wrote: post #52
bigethan wrote: post #7

This is why open source (and controlling your whole stack) matters in big business. For example, Microsoft may be changing their image, but their core software is closed source. may be great, but can you pull off something like this when you've got an issue? The importance of being able to debug and patch your mission critical systems is hard to overstate. Please encourage your employer to fiscally support the open s…

There's a different model in this case. You pay for support, and then the original developers go away and fix it for you. When this works well, it's great. You've got the experts on the problem. Not all support is good though, obviously, and if you have a mission critical problem that you need to fix overnight, nothing beats the 'self-support' that you can do with open source software.

Totally! Pay for support works when it's not urgent. But when your biz is hurting, it's hard to translate that urgency to another company that has _entirely_ different priorities than you do.

Reminds me of the heroku shaming posts that (then) rap genius had to do regarding dyanamo scaling and performance - http://genius.com/James-somers-herokus-ugly-secret-annotated They had no other way forward, even though they were paying the "experts"

This is why companies should pay open source contributors more frequently :-)

Re: The curious case of slow downloads

#56

Post by bigethan »

jamespo wrote: post #51
lmm wrote: post #50

Earlier quoted context omitted.

> So companies "should reward those who are generous with their code" but not compensate them for it? No, they absolutely should compensate them for it. Buy OSS.

"So you're asking me to pay for something we can get for free" said every Finance Officer ever...

"Hey CEO, There's an easy way I can increase team morale for less than the cost of a happy hour" said the VP of Engineering.

Re: The curious case of slow downloads

#57

Post by jamespo »

bigethan wrote: post #56
jamespo wrote: post #51

Earlier quoted context omitted.

"So you're asking me to pay for something we can get for free" said every Finance Officer ever...

"Hey CEO, There's an easy way I can increase team morale for less than the cost of a happy hour" said the VP of Engineering.

Can you explain how team morale improves if (for example) RHEL is used over Centos?
Post reply on HN