Live data from Hacker News

Why disaster happens at the edges: An introduction to queue theory

thenewstack.io

1–10 of 62 posts

Re: Why disaster happens at the edges: An introduction to queue theory

#3
post #2

> The TCP protocol, for instance, generates backpressure with code 503 Doesn't TCP typically use sliding window flow control? I'm not sure what "code" is referring to in this context.

That seems like a typo or confusion and they actually mean HTTP.

Re: Why disaster happens at the edges: An introduction to queue theory

#4
post #2

> The TCP protocol, for instance, generates backpressure with code 503 Doesn't TCP typically use sliding window flow control? I'm not sure what "code" is referring to in this context.

I think this might be an error in the text, HTTP status code 503 can be used for backpressure, which I think is what is being referred too

But yes, TCP uses windows for back-pressure, but that isn't really useful for application level backpressure as the OS controls the queues sizes, so pretty much most systems have their own backpressure on top.

Re: Why disaster happens at the edges: An introduction to queue theory

#7
Queueing theory-- my notes for programmers:

https://github.com/joelparkerhenderson/queueing-theory

Queueing theory is the mathematical study of waiting lines, or queues. We use queueing theory in our software development, for purposes such as project management kanban boards, inter-process communication message queues, and devops continuous deployment pipelines.

Re: Why disaster happens at the edges: An introduction to queue theory

#8
post #4
post #2

> The TCP protocol, for instance, generates backpressure with code 503 Doesn't TCP typically use sliding window flow control? I'm not sure what "code" is referring to in this context.

I think this might be an error in the text, HTTP status code 503 can be used for backpressure, which I think is what is being referred too But yes, TCP uses windows for back-pressure, but that isn't really useful for application level backpressure as the OS controls the queues sizes, so pretty much most systems have their own backpressure on top.

It's not that useless. A lot of applications these days are really using HTTP. And in HTTP/1 if you read from a response body from the socket (or write it), you are really already using the backpressure from TCP instead of having anything on top of it. With HTTP/2 and /3 that's different due to mulitplexing of multiple streams on the same socket - in that case there exists the additional flow control windows on top of TCP. These actually make those protocols rather hard to implement correctly.
Post reply on HN